Joyeux Vendredi a tous! Amis, aujourd'hui nous continuons la série de publications dédiées au cours , car les cours du nouveau groupe du cours commenceront à la fin de la semaine prochaine. Alors commençons !
La surveillance est juste. C'est un fait connu. Affichez Nagios, exécutez NRPE sur le système distant, configurez Nagios sur le port NRPE TCP 5666 et vous disposez d'une surveillance.
C'est tellement facile que ce n'est pas intéressant. Vous disposez désormais de métriques de base pour le temps CPU, le sous-système de disque, la RAM, fournies par défaut à Nagios et NRPE. Mais il ne s’agit pas réellement de « surveillance » en tant que telle. Ce n'est que le début.
(Habituellement, ils installent PNP4Nagios, RRDtool et Thruk, configurent les notifications dans Slack et accèdent directement à nagiosexchange, mais laissons cela de côté pour l'instant).
Bon suivi est en fait assez complexe, vous devez vraiment connaître les composants internes de l'application que vous surveillez.
Le suivi est-il difficile ?
N'importe quel serveur, qu'il soit Linux ou Windows, servira par définition à une certaine utilité. Apache, Samba, Tomcat, stockage de fichiers, LDAP : tous ces services sont plus ou moins uniques à un ou plusieurs égards. Chacun a sa propre fonction, ses propres caractéristiques. Il existe différentes manières d’obtenir des métriques, des KPI (indicateurs clés de performance), qui vous intéressent lorsque le serveur est en charge.
photo par sur
(J'aurais aimé que mes tableaux de bord soient bleu fluo - soupirant rêveusement -... hmm...)
Tout logiciel fournissant des services doit disposer d’un mécanisme permettant de collecter des métriques. Apache a un module mod-status, affichant la page d'état du serveur. Nginx a - stub_status. Tomcat dispose d'applications JMX ou Web personnalisées qui affichent des mesures clés. MySQL a une commande "show global status", etc.
Alors pourquoi les développeurs n’intègrent-ils pas des mécanismes similaires dans les applications qu’ils créent ?
Est-ce que seuls les développeurs font ça ?
Un certain niveau d'indifférence à l'égard de l'intégration de métriques ne se limite pas aux développeurs. J'ai travaillé dans des entreprises où elles développaient des applications à l'aide de Tomcat et ne fournissaient aucune de leurs propres métriques, aucun journal d'activité de service, à l'exception des journaux d'erreurs généraux de Tomcat. Certains développeurs génèrent beaucoup de logs qui ne signifient rien pour l'administrateur système qui a la malchance de les lire à 3h15 du matin.
photo par sur
Les ingénieurs système qui permettent la commercialisation de ces produits doivent également assumer une part de responsabilité dans la situation. Peu d’ingénieurs système ont le temps ou l’attention nécessaire pour essayer d’extraire des métriques significatives à partir des journaux, sans le contexte de ces métriques et la capacité de les interpréter à la lumière de l’activité des applications. Certains ne comprennent pas comment ils peuvent en bénéficier, à part les indicateurs « quelque chose ne va pas actuellement (ou va bientôt aller) ».
Un changement de mentalité concernant le besoin de métriques doit se produire non seulement parmi les développeurs, mais également parmi les ingénieurs système.
Pour tout ingénieur système qui doit non seulement répondre aux événements critiques, mais également s'assurer qu'ils ne se produisent pas, le manque de mesures constitue généralement un obstacle à cette tâche.
Cependant, les ingénieurs système ne bricolent généralement pas le code pour gagner de l’argent pour leur entreprise. Ils ont besoin de développeurs principaux qui comprennent l'importance de la responsabilité de l'ingénieur système dans l'identification des problèmes, la sensibilisation aux problèmes de performances, etc.
Ce truc de développeur
La mentalité DevOps décrit la synergie entre la pensée développement (dev) et opérationnelle (ops). Toute entreprise qui prétend « faire du devops » doit :
- dire des choses qu'ils ne disent probablement pas (en référence au mème The Princess Bride - "Je ne pense pas que cela signifie ce que vous pensez que cela signifie!")
- Encourager une attitude d’amélioration continue des produits.
Vous ne pouvez pas améliorer un produit et savoir qu'il a été amélioré si vous ne savez pas comment il fonctionne actuellement. Vous ne pouvez pas savoir comment fonctionne un produit si vous ne comprenez pas comment fonctionnent ses composants, les services dont il dépend, ses principaux problèmes et goulots d'étranglement.
Si vous ne surveillez pas les goulots d'étranglement potentiels, vous ne pourrez pas suivre la technique des cinq pourquoi lors de la rédaction d'un post-mortem. Vous ne pourrez pas tout mettre sur un seul écran pour voir comment fonctionne un produit ou savoir à quoi il ressemble « normal et heureux ».
Décalage à gauche, à gauche, j'ai dit LEEEE—
Pour moi, l’un des principes clés de Devops est le « shift left ». Dans ce contexte, déplacer vers la gauche signifie déplacer la possibilité (aucune responsabilité, mais uniquement les capacités) pour effectuer des tâches qui intéressent généralement les ingénieurs système, telles que la création de mesures de performances, l'utilisation plus efficace des journaux, etc., à gauche dans le cycle de vie de livraison de logiciels.
photo par sur
Les développeurs de logiciels doivent être capables d'utiliser et de connaître les outils de surveillance que l'entreprise utilise afin d'effectuer la surveillance sous toutes ses formes, métriques, journalisation, interfaces de surveillance et, surtout, regardez comment leur produit fonctionne en production. Vous ne pouvez pas amener les développeurs à investir du temps et des efforts dans la surveillance jusqu'à ce qu'ils puissent voir les métriques et influencer leur apparence, la façon dont le propriétaire du produit les présente au CTO lors du prochain briefing, etc.
En bref
- Menez votre cheval à l'eau. Montrez aux développeurs combien de problèmes ils peuvent éviter pour eux-mêmes, aidez-les à identifier les bons KPI et les bonnes mesures pour leurs applications afin qu'il y ait moins de cris de la part du propriétaire du produit qui se fait interpeller par le CTO. Amenez-les à la lumière, doucement et calmement. Si cela ne fonctionne pas, soudoyez-les, menacez-les et cajolez-les ou le propriétaire du produit pour qu'ils mettent en œuvre l'obtention de ces métriques à partir des applications le plus rapidement possible, puis dessinez les diagrammes. Cela sera difficile car cela ne sera pas considéré comme une priorité et la feuille de route du produit comportera de nombreux projets générateurs de revenus en attente. Par conséquent, vous aurez besoin d’une analyse de rentabilisation pour justifier le temps et les dépenses consacrés à la mise en œuvre de la surveillance dans le produit.
- Aidez les ingénieurs système à passer une bonne nuit de sommeil. Montrez-leur qu'utiliser une liste de contrôle « sortions » pour tout produit en cours de sortie est une bonne chose. Et s'assurer que toutes les applications en production sont couvertes par des métriques vous aidera à mieux dormir la nuit en permettant aux développeurs de voir ce qui ne va pas et où. Cependant, la bonne façon d’irriter et de frustrer tout développeur, propriétaire de produit ou CTO est de persister et de résister. Ce comportement aura un impact sur la date de sortie de n'importe quel produit si vous attendez à nouveau la dernière minute, alors déplacez-vous encore vers la gauche et intégrez ces problèmes dans votre plan de projet dès que possible. Si nécessaire, rendez-vous aux réunions de produits. Portez une fausse moustache et du feutre ou quelque chose du genre, cela n'échouera jamais. Communiquez vos préoccupations, démontrez des avantages clairs et évangélisez.
- Assurez-vous que le développement (dev) et les opérations (ops) comprennent la signification et les conséquences du passage des métriques du produit dans la zone rouge. Ne laissez pas Ops comme seul gardien de la santé des produits, assurez-vous que les développeurs sont également impliqués (#productsquads).
- Les journaux sont une bonne chose, tout comme les métriques. Combinez-les et ne laissez pas vos bûches devenir des déchets dans une énorme boule enflammée d'inutilité. Expliquez et montrez aux développeurs pourquoi personne d'autre ne comprendra leurs logs, montrez-leur ce que c'est que de consulter des logs inutiles à 3h15 du matin.
photo par sur
C'est tout. Du nouveau matériel sera publié la semaine prochaine. Si vous souhaitez en savoir plus sur le cours, nous vous invitons à , qui aura lieu lundi. Et maintenant, nous attendons traditionnellement vos commentaires.
Source: habr.com