Nous utilisons un compte Azure Storage pour stocker certains fichiers qui seront téléchargés par notre application à la demande des utilisateurs.
Même s'il ne devrait y avoir aucune opération d'écriture (du moins aucune à laquelle je pourrais penser), nous dépassons les opérations d'écriture incluses quelques jours seulement après le début de la période de facturation (voir l'image).
Concernant le prix, c'est toujours dans les limites, mais j'aimerais quand même savoir si c'est normal et comment je peux analyser la question. Outre le stockage que nous utilisons
mais aucun d'entre eux ne devrait provoquer autant d'opérations d'écriture. J'ai vérifié les journaux de nos fonctions et aucune de celles qui accèdent aux files d'attente ou aux blobs n'a été active ces derniers temps. Il y a des fonctions qui s'exécutent de temps en temps, mais seulement une fois toutes les quelques minutes et celles-ci n'accèdent pas du tout au stockage.
Je ne sais pas si cela est lié, mais il y a une sorte d'entrée périodique sur notre stockage d'objets blob (voir l'image ci-dessous). La période est d'environ 1 h, mais il y a une ligne de base de 100 ko par 5 min.
En analysant plus avant les métriques du compte de stockage, j'ai trouvé qu'il y avait un flux constant de 1,90k transactions par heure pour les blobs et 1,3k transactions par heure pour les files d'attente, ce qui me semble assez exceptionnel. (Veuillez noter que la résolution de ce graphique est de 1 h, tandis que le premier a une résolution de 5 minutes)
Puis-je faire autre chose pour analyser d'où viennent les opérations d'écriture? Cela me dérange un peu, car il ne semble pas que ce soit censé être comme ça.
3 Réponses :
Le meilleur endroit pour trouver des informations sur l'utilisation du stockage est d'utiliser Storage Analytics , en particulier Journalisation de Storage Analytics .
Il existe un conteneur d'objets blob spécial appelé $ logs dans le même compte de stockage, qui contiendra des informations détaillées sur chaque opération effectuée sur ce compte de stockage. Vous pouvez afficher les objets blob dans ce conteneur d'objets blob et trouver les informations.
Si vous ne voyez pas ce conteneur d'objets blob dans votre compte de stockage, vous devrez activer les analyses de stockage sur votre compte de stockage. Cependant, étant donné que vous pouvez voir les données de métriques, je suppose qu'elles sont déjà activées.
Concernant la source de ces opérations d'écriture, avez-vous activé les diagnostics pour vos Functions et App Service? Ceux-ci écrivent des journaux de diagnostic dans le stockage d'objets blob. En outre, l'analyse du stockage écrit également sur le même compte, ce qui entraînera également ces opérations d'écriture.
Je suis confronté à ce même problème, je ne l'ai jamais eu auparavant, rien de nouveau sur Storage Analytics Logging, chaque opération journalisée est stockée en tant que Cold et est alignée avec mon journal d'application, je ne peux pas trouver la source de cette opération d'écriture LRS, mon seul suppose que certaines opérations LRS cachées qui ne sont pas accessibles au public depuis le portail azure, telles que les sauvegardes de bases de données, sont effectuées plus fréquemment, vous ne pouvez pas savoir avec certitude, d'autres conseils?
@PauloLima Je suis moi aussi confronté à ce problème et j'ai ouvert un autre message. Avez-vous eu de la chance pour résoudre ce problème de votre côté? Je n'ai pas eu de chance jusqu'à présent stackoverflow.com/questions/57654009
@MarkB rien ici, j'ai un ticket ouvert sur l'équipe de support Azure depuis un certain temps (un mois peut-être) et ils ne peuvent pas me fournir de réponse à cette question, ni ils n'ont pu filtrer de leur côté pour les blobs chauds .
@MarkB s'avère qu'aujourd'hui j'ai reçu une réponse: "Les fichiers auxquels on accède constamment apparaîtront comme Hot même s'ils sont configurés comme cool."
@PauloLima J'ai moi aussi un ticket ouvert avec MSFT. ravi de voir que vous avez enfin obtenu une réponse, quoique un peu inutile je pense! Le plus drôle de mon côté, c'est que je n'utilise pas du tout le stockage de fichiers! Ce qui amène à poser la question ... CE QUI EST ÉCRIT DANS MES FICHIERS!
@MarkB c'est sérieux, si j'ai d'autres mises à jour, je vous tiendrai informé.
J'ai eu exactement le même problème; après avoir activé Storage Analytics et inspecté le conteneur $ logs , j'ai trouvé de nombreuses entrées de journal qui indiquent qu'à chaque demande adressée à mes fonctions Azure, ces opérations d'écriture se produisent sur l'objet conteneur suivant:
Dans mon code Azure Functions, je n'écris explicitement dans aucun conteneur ou fichier en tant que tel, mais les deux paramètres d'application suivants sont configurés:
J'ai donc rempli un ticker d'assistance dans Azure avec les questions suivantes:
et j'ai obtenu les réponses suivantes de l'équipe d'assistance Azure, respectivement:
azure-webjobs-hosts est associé à l'application de fonction et il est créé par défaut en plus de créer une application de fonction. Lorsque l'application de fonction est en cours d'exécution, elle enregistre ces journaux dans le compte de stockage qui est configuré avec AzureWebJobsStorage . AzureWebJobsStorage . Le runtime Azure Functions utilise cette chaîne de connexion de compte de stockage pour toutes les fonctions à l'exception des fonctions déclenchées par HTTP. La suppression de ces paramètres d'application empêchera votre application de fonction de démarrer. En passant, vous pouvez supprimer AzureWebJobsDashboard et cela arrêtera Monitor plutôt que l'opération ci-dessus. Pour mon cas, j'ai un Azure App Insight qui a pris 10K transactions sur son stockage par minute pour les fonctions et les services d'application, même s'il n'y a que peu de requêtes https parmi elles. Je ne suis pas sûr de ce qui les déclenche, mais une fois que j'ai supprimé les statistiques d'application, tout devient normal.
Avez-vous eu de la chance pour trouver la source de ce problème? Je suis sur le point de croire que ce n'est pas directement aux comptes de stockage, mais aux sauvegardes automatiques, des tests seront effectués demain.