Use automated builds linked to Github-based Dockerfiles rather than pushing local image builds. Not only does this make the Dockerfile transparently available and provide a link to the repository where one can file issues, but it also helps ensure that the image available on the hub gets its base image (FROM entry) from the hub instead of whatever was available locally. This can help avoid various out-of-sync errors that might otherwise emerge.
Encore une discussion intéressante sur les perf de graphite. Ce qu'il faut retenir c'est que le botteneck peut se situer au niveau du CPU ou au niveau du disque (la RAM en général ce n'est pas un probleme, meme si bien sur, il faut la surveiller)
Pour connaitre l'utilisation du CPU de carbon-cache, une metric est envoyé par le daemon dans carbon.agents.graphite-x.cpuUsage
Pour connaitre l'utilisation du disk, on se sert de iostat -dmx 1 2 (merci arnaud)
Si le disque est trop haut (entre 50 et 75), il faut le soulager en baissant dans la conf de carbon le max update par seconde.
Ce qui aura pour effet d'augmenter la taille du cache et donc de faire plus travailler le CPU..
Au contraire si le CPU est chargé mais que le disque ne fait rien, il faut augmenter le max update par seconde.
En trouvant le bon équilibre on peut exploiter au maximum le hardware disponible
curl http://bot.whatismyipaddress.com
Une parmi d'autres qui a l'avantage d'être rapide ;)
une liste de jeux, yen a surement des biens à tester
Encore des liens devops, toujours via arnaudb (https://arnaudb.net/)
Une liste d'outils devops, bien foutu ! merci arnaudb
Pour voir rapidement si il y a des l'activité sur une instance redis :
redis-cli info | grep -E 'used_memory:|changes|commands_processed'
à lancer plusieurs fois et voir si les résultats changent
ou bien un bon vieux tcpdump : tcpdump -i any dst port [port redis]
Ma préféré :
Mais non, t’as pas besoin de specs pour coder.
via sebsauvage
Pour exposer du RO ES sur certains index, à certaines personnes..
Un screenshot d'un dashboard qu'il est bien
le server-status de nginx : comment interpréter l'output
Interpretation
Active connections – Number of all open connections. This doesn’t mean number of users. A single user, for a single pageview can open many concurrent connections to your server.
Server accepts handled requests – This shows three values.
First is total accepted connections.
Second is total handled connections. Usually first 2 values are same.
Third value is number of and handles requests. This is usually greater than second value.
Dividing third-value by second-one will give you number of requests per connection handled by Nginx. In above example, 10993/7368, 1.49 requests per connections.
Reading – nginx reads request header
Writing – nginx reads request body, processes request, or writes response to a client
Waiting – keep-alive connections, actually it is active – (reading + writing).This value depends on keepalive-timeout. Do not confuse non-zero waiting value for poor performance. It can be ignored. Although, you can force zero waiting by setting keepalive_timeout 0;