Filebeat utilise des template de mapping (pour chaque version de filebeat, un nouveau template est créé)
Donc l'index créé tous les jours par filebeat a un mapping qui provient de ce template
Il y a beaucoup de champs défini qui proviennent de la déclaration de tous les modules filebeat (https://github.com/elastic/beats/blob/master/filebeat/module/nginx/access/_meta/fields.yml)
Si on a besoin de déclarer de nouveaux champs, on peut créer son propre template qui va matcher aussi les index filebeat-* et qui va surcharger les templates de filebeat
Alternative : on peut vérifier que le champs n'existe pas déjà dans les champs prédéfini de filebeat. Par exemple le $status de nginx (code retour http) correspond au champs http.response.status_code
Il suffit que le json écrit par nginx ait une clé qui correspond pour le status pour avoir le bon mapping
https://www.elastic.co/guide/en/beats/filebeat/master/configuration-template.html
Exemple pour le field 'status' :
for index in $(cat liste_index); do echo $index; curl -s http://elastic/$index/_mapping | jq ".\"$index\".mappings.doc.properties.status"; done
Peut être utile dans certains cas, je me le garde de côté
Should have a clear understanding of standard web development processes and best practices
Is a strong communicator who can explain technical concepts in an understandable manner
Is comfortable rapidly writing throwaway code that gets the job done -- even if it’s not well-optimized, well-tested, or well-architected
Cares more about the business impact of the work than the elegance of the technical solution
Must be detail-oriented, self-organized and capable of tracking multiple tasks simultaneously
Lol
Pour obtenir les yaml sans installer un helm chart :
helm template \
--values ./values/prometheus.yaml \
--output-dir ./manifests \
./charts/prometheus
Prometheus Operator vs. kube-prometheus
The Prometheus Operator makes the Prometheus configuration Kubernetes native and manages and operates Prometheus and Alertmanager clusters. It is a piece of the puzzle regarding full end-to-end monitoring.
kube-prometheus combines the Prometheus Operator with a collection of manifests to help getting started with monitoring Kubernetes itself and applications running on top of it.
https://github.com/coreos/prometheus-operator/tree/master/contrib/kube-prometheus
Pour un graceful shutdown de nginx, il faut un SIGQUIT
Kubernetes envoie du SIGTERM alors on peut utiliser un preStop script pour être + cool
https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/#define-poststart-and-prestop-handlers
On peut aussi utiliser le preStop pour s'assuret que le container nginx sidecar s'arrête bien avant l'autre container en posant un lock dans un shared volume. Le preStop de l'autre container va attendre que le lock soit supprimé pour se couper. Le preStop du nginx va supprimer le lock quand il a bien terminé.
On crée le lock dans un postStart
via Meetup k8s bbc speaker
tcp6 0 0 :::61678 :::* LISTEN 0 81586 32466/aws-k8s-agent
Tous les nodes exposent ça, c'est cool, ils auraient pu en parler dans la doc ;)
curl localhost:61678/metrics