J'ai écrit une API et je regarde actuellement quel est le meilleur moyen de fournir la journalisation du système.
Nous voulons pouvoir avoir une vue d'ensemble des appels réalisés, si des appels particuliers sont frappés très souvent et tels.
Quelle est la meilleure façon de vous connecter et de présenter toutes ces informations simplement?
Vous vous demandez simplement s'il existe des solutions pré-construites ou couramment utilisées avec des API qui englobent ce que je cherche.
4 Réponses :
Une solution simple serait de connecter tous les appels vers un fichier, peut-être dans un format similaire à Apache Web Server des journaux. Ensuite, vous pouvez analyser le journal avec un outil Analyse de journal existant, par exemple Webalizer.
Vous mentionnez des solutions "pré-construites" - avez-vous donc envisagé d'utiliser un service externe pour cela? Par exemple. Jetez un coup d'œil à http://www.webservius.com - Il fournit de nombreuses fonctionnalités de gestion de l'API et peuvent faire Différents types d'analyses (par exemple, l'affichage des appels sont utilisés le plus souvent, par lequel l'utilisateur, etc.)
Malheureusement finira beaucoup trop cher pour nos besoins.
Vous pouvez me contacter hors ligne à Eugene chez Webservius Dot Com avec vos besoins exacts (volumes d'appel attendus, etc.) et nous pourrons peut-être comprendre quelque chose.
Il y a plusieurs façons de faire cela. Je commencerais par une solution de journalisation abstraite d'abord, quelque chose comme Monolog [https://github.com/seldaek/monolog]. De cette façon, vous pouvez tester et jouer avec ce que vous souhaitez vous connecter dans un fichier texte pour commencer, puis passer à une solution plus élégante.
Monologue a des gestionnaires pour un tas de différents services / conteneurs de ligging. Pour la journalisation de l'utilisation de l'API, je jetterais un coup d'oeil à ce qui suit:
grislog2 , un très bon système de journalisation open source.
cube , également un grand projet open source pour collecter des événements horodataires.
loggly , une plate-forme de journalisation basée sur le cloud commercial. Monologue n'a pas de gestionnaire pour logply en ce moment, mais j'en ai écrit celui que j'utilise actuellement en production. Ma fourchette du projet monologue a ce gestionnaire, je prévois de soumettre une demande de retrait bientôt: Télécharger sur Gitub ici .
Sentry , une plate-forme de journalisation et d'agrégation d'événement en temps réel que vous pouvez vous héberger ou utiliser la version accueillie payée. . Comme Loggly, pas de gestionnaire de monologue pour cela, mais c'est un très beau projet avec une API agréable, vous pouvez facilement écrire un code simple pour vous connecter.
envisager une approche journal est un flux
Les journaux sont un flux et qui couvre tout le monde à les traiter comme tel. Vos programmes doivent se connecter à STDOUT et / ou StDerR et omettez toute tentative de manipuler les chemins de journalisation, la rotation du journal ou l'envoi de journaux sur le protocole Syslog. Diriger où se passe le flux de journal du programme peut être laissé au conteneur d'exécution: un terminal local ou une IDE (dans les environnements de développement), un script de lancement UPSTART / SYSTEMD (dans les environnements d'hébergement traditionnels) ou un système comme LogPlex / Heroku (dans une environnement de plate-forme).
(Je l'ai remarqué dans ce Réponse , qui est originaire de ce Article )
Une bonne chose est marquée dans la réponse de @emil Vikström , qui est nécessaire de remarquer, est un
Êtes-vous sûr de vouloir Log Cette information? Pour moi, ça sonne comme si tu veux Profil et Stresstest .
Nous voulons nous connecter, nous sommes donc en mesure de voir si certains utilisateurs appellent trop d'appel (oui, nous avons une limitation de taux, mais toujours bien de savoir si les gens essaient d'abuser). En plus de voir où vient vraiment le grand usage, combien d'erreurs se produisent, ce genre de choses amusantes.
James, as-tu trouvé une bonne solution? Je suis intéressé par la même question.