Forums » Discussions & Questions »
Le container logstash ne démarre pas
Ajouté par Nicolas E il y a environ 4 ans
Bonjour,
Après avoir installé un tout nouveau serveur XivoCC en Freya.02, je lance l'install selon la documentation, puis quand je lance les docker compose ("xivocc-dcomp up -d"), je constate que tous s'initialisent et tournent correctement (je peux utiliser leurs services) sauf celui de logstash.
En le lançant à la main, je vois que le problème vient d'une table SQL :
logstash_1 | Waiting for Elasticsearch cluster to respond ... logstash_1 | Waiting for Elasticsearch cluster to be ready ... urllib3.connectionpool._make_request: http://localhost:None "GET /v1.38/events?filters=%7B%22label%22%3A+%5B%22com.docker.compose.project%3Dxivocc%22%2C+%22com.docker.compose.oneoff%3DFalse%22%5D%7D HTTP/1.1" 200 None compose.cli.verbose_proxy.proxy_callable: docker events -> <docker.types.daemon.CancellableStream object at 0x7f484dbe3860> logstash_1 | Waiting for Elasticsearch cluster to respond (1/180) logstash_1 | logstash_1 | Elasticsearch docker-cluster is up and running on http://elasticsearch:9200 logstash_1 | logstash_1 | logstash_1 | Running logstash pre-start hook logstash_1 | logstash_1 | logstash_1 | Initializing queue_log last value to take 7 days of history logstash_1 | logstash_1 | ERREUR: la relation « queue_log » n'existe pas logstash_1 | LINE 1: select min(id) from queue_log where cast(time as timestamp) ... logstash_1 | ^
Si j'ajoute un entrypoint à /etc/docker/compose/docker-xivocc.yml, et que je le lance manuellement (docker-compose -p xivocc -f /etc/docker/compose/docker-xivocc.yml --verbose up logstash), et que j'entre dans le container (docker-compose -f /etc/docker/compose/docker-xivocc.yml -p xivocc exec -u 0 logstash bash), je constate que /etc/logstash/logstash.yml fait référence, dans sa définition d'input ciblant la base posgresql "xivo_stats", à /etc/logstash/queuelog_query.sql qui est une requête qui appelle la table queue_log.
Or, quand je rentre de la même manière dans le container de pgxivocc, puis en tant que user postgres, la liste des tables ne montre pas de table queue_log :
You are now connected to database "xivo_stats" as user "postgres".
xivo_stats=# \dt
List of relations
Schema | Name | Type | Owner
--------+----------------------------+-------+----------
public | agent_position | table | asterisk
public | agent_states | table | asterisk
public | attached_data | table | asterisk
public | call_data | table | asterisk
public | call_element | table | asterisk
public | call_on_queue | table | asterisk
public | callback_ticket | table | asterisk
public | databasechangelog | table | asterisk
public | databasechangeloglock | table | asterisk
public | hold_periods | table | asterisk
public | last_cel_id | table | asterisk
public | last_queue_log_id | table | asterisk
public | queue_specific_time_period | table | asterisk
public | queue_threshold_time | table | asterisk
public | stat_agent_periodic | table | asterisk
public | stat_agent_queue_specific | table | asterisk
public | stat_agent_specific | table | asterisk
public | stat_queue_periodic | table | asterisk
public | stat_queue_specific | table | asterisk
public | transfers | table | asterisk
public | xc_call_channel | table | asterisk
public | xc_call_conversation | table | asterisk
public | xc_call_transfer | table | asterisk
public | xc_queue_call | table | asterisk
(24 rows)
Alors peut-être que je n'ai pas bien compris quelle base était censée être ciblée, et j'avoue que je connais très mal docker et son fonctionnement.
J'ai quand même pris le temps de pinguer les containers entre eux, y compris en utilisant leurs id et leurs hostname, et tout fonctionne bien.
Mais là, j'ai bien l'impression qu'il manque une table, non ?
Cordialement,
Nicolas
Réponses (3)
RE: Le container logstash ne démarre pas - Ajouté par Nicolas E il y a environ 4 ans
Ce qui est curieux, c'est que la base postgreSQL située dans le Xivo contient une base nommée asterisk, qui - elle au moins - contient une table nommée queue_log, et qui répondRAIT correctement à la requête du statement_filepath...
RE: Le container logstash ne démarre pas - Ajouté par Laurent MEILLER il y a environ 4 ans
Bonjour Nicolas,
C'est bizarre, en effet la table queue_log est une table généré par Asterisk qu'on retrouve dans le schéma db du serveur XiVO. Mais ce n'est pas cette base qui est utilisé par logstash pour son provisioning.
Pour être précis, on a un docker (db_replic) sur le serveur xivo qui comme son nom l'indique copie certaines tables (en gros queue_log et cel) sur notre serveur de reporting du XiVOCC, à partir de là on génère des stats, l'historique d'appel pour nos interfaces et pas mal d'autre trucs.
C'est ce schema xivo-stats sur la db du XIVOCC qui devrait contenir la table queue_log et est attaqué par logstash pour permettre à kibana d'afficher les graphiques.
1 - Regarder au cas où les logs via xivo-dcomp logs db_replic si il n'y a pas d'erreurs de réplication de base à base
2 - Vérifier dans /etc/docker/xivo/custom.env sur XIVO si vous avez bien :
REPORTING_DB_HOST='votre_ip_xivocc'
ELASTICSEARCH='votre_ip_xivocc'
Si c'est pas le cas, modifier et relancer un xivo-dcomp up -d
Si rien ne marche, on pourra envisager de benner la base stats et la recréer, mais c'est un peu plus périlleux. Une réinstalle fraîche du CC, serait plus judicieux et plus rapide.
RE: Le container logstash ne démarre pas - Ajouté par Nicolas E il y a environ 4 ans
Bonjour Laurent,
C'était déjà une installation from scratch après un formatage de serveur.
Dans /etc/docker/xivo/custom.env, les valeurs que j'avais pour le ip des REPORTING_DB_HOST et ELASTICSEARCH n'étaient pas celle du serveur XivoCC, mais celle des interfaces docker du XivoCC.
Les containers n'avaient donc aucune chance de discuter entre eux.
Et en effet, les logs docker du container de réplication montraient une impossibilité de discussion.
J'ai modifié ces deux champs comme vous l'avez conseillé, en pointant vers l'ip du XivoCC, relancé tous les services, et désormais, je vois bien :
- mon container logstash démarrer
- le flux logstash apparaître dans Kibana > Monitoring
- SpagoBI : Pas encore de data, mais mes rapports s'affichent désormais sans planter, contrairement à avant
J'ignore comment les mauvaises ip se sont retrouvées dans custom.env, et je suppose que ça peut valoir la peine de faire remonter l'info côté devs ?
Merci pour votre aide.
Bonne journée.
Nicolas