> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Superviser les logs Systemd avec ClickStack
> Superviser les logs Systemd et Journald avec ClickStack
export const TrackedLink = ({href, eventName, children, ...rest}) => {
const handleClick = () => {
try {
if (typeof window !== "undefined" && window.galaxy && eventName) {
window.galaxy.track(eventName, {
interaction: "click"
});
}
} catch (e) {}
};
return
{children}
;
};
export const Image = ({img, alt, size = "lg"}) => {
const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg";
return ;
};
**En bref**
Collectez et visualisez les logs du journal systemd dans ClickStack à l’aide du receiver journald de l’OpenTelemetry Collector. Comprend un jeu de données de démonstration et un tableau de bord préconfiguré.
## Intégration avec les systèmes existants
Surveillez les logs journald de votre système Linux actuel en exécutant l’OpenTelemetry Collector avec le journald receiver pour collecter les logs système et les envoyer à ClickStack via OTLP.
Si vous souhaitez d’abord tester cette intégration sans modifier votre configuration actuelle, passez à la [section sur le jeu de données de démonstration](#demo-dataset).
##### Prérequis
* Une instance ClickStack en cours d’exécution
* Système Linux avec systemd (Ubuntu 16.04+, CentOS 7+, Debian 8+)
* Docker ou Docker Compose installé sur le système surveillé
L'OpenTelemetry Collector envoie les données vers le point de terminaison OTLP de ClickStack, qui nécessite une authentification.
1. Ouvrez HyperDX à l'URL de votre instance ClickStack (par ex. [http://localhost:8080](http://localhost:8080))
2. Créez un compte ou connectez-vous si nécessaire
3. Accédez à **Team Settings → API Keys**
4. Copiez votre **Ingestion API Key**
5. Définissez-la comme variable d'environnement :
```bash theme={null}
export CLICKSTACK_API_KEY=your-api-key-here
```
Assurez-vous que votre système utilise systemd et dispose de journaux journalctl :
```bash theme={null}
# Vérifier la version de systemd
systemctl --version
# Afficher les entrées récentes du journal
journalctl -n 20
# Vérifier l'utilisation disque du journal
journalctl --disk-usage
```
Si le journal est stocké uniquement en mémoire, activez le stockage persistant :
```bash theme={null}
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald
```
Créez un fichier de configuration pour l'OpenTelemetry Collector :
```yaml theme={null}
cat > otel-config.yaml << 'EOF'
receivers:
journald:
directory: /var/log/journal
priority: info
units:
- sshd
- nginx
- docker
- containerd
- systemd
processors:
batch:
timeout: 10s
send_batch_size: 10000
resource:
attributes:
- key: service.name
value: systemd-logs
action: insert
- key: host.name
from_attribute: _HOSTNAME
action: upsert
attributes:
actions:
- key: unit
from_attribute: _SYSTEMD_UNIT
action: upsert
- key: priority
from_attribute: PRIORITY
action: upsert
exporters:
otlphttp:
endpoint: ${CLICKSTACK_ENDPOINT}
headers:
authorization: ${CLICKSTACK_API_KEY}
service:
pipelines:
logs:
receivers: [journald]
processors: [resource, attributes, batch]
exporters: [otlphttp]
EOF
```
Le receiver `journald` nécessite le binaire `journalctl` pour lire les fichiers du journal. L'image officielle `otel/opentelemetry-collector-contrib` n'inclut pas `journalctl` par défaut.
Pour les déploiements conteneurisés, vous pouvez soit installer le collector directement sur l'hôte, soit créer une image personnalisée avec les utilitaires systemd. Consultez la [section de dépannage](#journalctl-not-found) pour plus de détails.
Cet exemple montre comment déployer l'OTel Collector aux côtés de ClickStack :
```yaml theme={null}
services:
clickstack:
image: clickhouse/clickstack-all-in-one:latest
ports:
- "8080:8080"
- "4317:4317"
- "4318:4318"
networks:
- monitoring
otel-collector:
image: otel/opentelemetry-collector-contrib:0.115.1
depends_on:
- clickstack
environment:
- CLICKSTACK_API_KEY=${CLICKSTACK_API_KEY}
- CLICKSTACK_ENDPOINT=http://clickstack:4318
volumes:
- ./otel-config.yaml:/etc/otelcol/config.yaml:ro
- /var/log/journal:/var/log/journal:ro
- /run/log/journal:/run/log/journal:ro
- /etc/machine-id:/etc/machine-id:ro
command: ["--config=/etc/otelcol/config.yaml"]
networks:
- monitoring
networks:
monitoring:
driver: bridge
```
Démarrez les services :
```bash theme={null}
docker compose up -d
```
Une fois la configuration en place, connectez-vous à HyperDX et vérifiez que les logs arrivent bien :
1. Accédez à la vue Search
2. Définissez la source sur Logs
3. Filtrez sur `service.name:systemd-logs`
4. Vous devriez voir des entrées de log structurées avec des champs comme `unit`, `priority`, `MESSAGE`, `_HOSTNAME`
## Jeu de données de démonstration
Pour les utilisateurs qui souhaitent tester l’intégration des logs systemd avant de configurer leurs systèmes de production, nous fournissons un jeu de données d’exemple contenant des logs systemd pré-générés avec des motifs réalistes.
Téléchargez le fichier de logs d’exemple :
```bash theme={null}
curl -O https://datasets-documentation.s3.eu-west-3.amazonaws.com/clickstack-integrations/systemd/systemd-demo.log
```
Créez un fichier de configuration pour la démonstration :
```bash theme={null}
cat > systemd-demo.yaml << 'EOF'
receivers:
filelog:
include:
- /tmp/systemd-demo/systemd-demo.log
start_at: beginning
operators:
- type: regex_parser
regex: '^(?P\S+) (?P\S+) (?P\S+?)(?:\[(?P\d+)\])?: (?P.*)$'
parse_from: body
parse_to: attributes
- type: time_parser
parse_from: attributes.timestamp
layout: '%Y-%m-%dT%H:%M:%S%z'
- type: add
field: attributes.source
value: "systemd-demo"
service:
pipelines:
logs/systemd-demo:
receivers: [filelog]
processors:
- memory_limiter
- transform
- batch
exporters:
- clickhouse
EOF
```
Démarrez ClickStack avec les logs de démonstration :
```bash theme={null}
docker run -d --name clickstack-demo \
-p 8080:8080 -p 4317:4317 -p 4318:4318 \
-e CUSTOM_OTELCOL_CONFIG_FILE=/etc/otelcol-contrib/custom.config.yaml \
-v "$(pwd)/systemd-demo.yaml:/etc/otelcol-contrib/custom.config.yaml:ro" \
-v "$(pwd)/systemd-demo.log:/tmp/systemd-demo/systemd-demo.log:ro" \
clickhouse/clickstack-all-in-one:latest
```
La démonstration utilise le receiver `filelog` avec des logs texte au lieu de `journald`, afin d’éviter d’avoir à utiliser `journalctl` dans le conteneur.
Une fois ClickStack démarré :
1. Ouvrez [HyperDX](http://localhost:8080/) et connectez-vous à votre compte
2. Accédez à la vue Search et définissez la source sur `Logs`
3. Définissez l’intervalle de temps sur **2025-11-14 00:00:00 - 2025-11-17 00:00:00**
**Affichage du fuseau horaire**
HyperDX affiche les timestamps dans le fuseau horaire local de votre navigateur. Les données de démonstration couvrent la période **2025-11-15 00:00:00 - 2025-11-16 00:00:00 (UTC)**. Cet intervalle de temps élargi vous permet de voir les logs de démonstration où que vous soyez.
## Tableaux de bord et visualisations
Pour vous aider à démarrer la surveillance des logs systemd avec ClickStack, nous fournissons des visualisations essentielles pour les données du journal systemd.
Télécharger le fichier de configuration du tableau de bord.
1. Ouvrez HyperDX et accédez à la section Dashboards
2. Cliquez sur **Import Dashboard** dans l’angle supérieur droit, sous les points de suspension
3. Téléversez le fichier `systemd-logs-dashboard.json`, puis cliquez sur **Finish Import**
Le tableau de bord comprend des visualisations pour :
* Le volume de logs au fil du temps
* Les principales unités systemd par nombre de logs
* Les événements d’authentification SSH
* Les défaillances de service
* Les taux d’erreur
Pour le jeu de données de démonstration, définissez l’intervalle de temps sur **2025-11-15 00:00:00 - 2025-11-16 00:00:00 (UTC)** (à ajuster selon votre fuseau horaire local).
## Dépannage
### Aucun log n’apparaît dans HyperDX
Vérifiez si les logs parviennent à ClickHouse :
```bash theme={null}
docker exec clickstack clickhouse-client --query "
SELECT COUNT(*) as log_count
FROM otel_logs
WHERE ServiceName = 'systemd-logs'
"
```
Si aucun résultat n’est renvoyé, vérifiez les logs du collector :
```bash theme={null}
docker logs otel-collector | grep -i "error\|journald" | tail -20
```
### erreur « journalctl introuvable »
Si vous voyez `exec: "journalctl": executable file not found in $PATH` :
L’image `otel/opentelemetry-collector-contrib` n’inclut pas `journalctl`. Vous pouvez :
1. **Installer le collector sur l’hôte** :
```bash theme={null}
wget https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v0.115.0/otelcol-contrib_0.115.0_linux_amd64.tar.gz
tar -xzf otelcol-contrib_0.115.0_linux_amd64.tar.gz
sudo mv otelcol-contrib /usr/local/bin/
otelcol-contrib --config=otel-config.yaml
```
2. **Utilisez l’approche par exportation de texte** (comme dans la démo) avec le receiver `filelog` qui lit les exports journald
## Étapes suivantes
* Configurez des [alertes](/docs/fr/clickstack/features/alerts) pour les événements système critiques (pannes de services, échecs d'authentification, arrêts OOM)
* Créez des [tableaux de bord](/docs/fr/clickstack/features/dashboards/overview) supplémentaires pour des cas d'utilisation spécifiques (surveillance de la sécurité SSH, état de santé des services)
* Filtrez sur des unités systemd spécifiques pour réduire le bruit et vous concentrer sur les services essentiels
## Passage en production
Ce guide utilise un OpenTelemetry Collector distinct pour lire les logs systemd et les envoyer au point de terminaison OTLP de ClickStack, ce qui constitue l’approche recommandée en production.
Pour les environnements de production comportant plusieurs hôtes, envisagez :
* de déployer le collector sous forme de DaemonSet dans Kubernetes
* d’exécuter le collector en tant que service systemd sur chaque hôte
* d’utiliser l’OpenTelemetry Operator pour automatiser le déploiement
Consultez [Ingesting with OpenTelemetry](/docs/fr/clickstack/ingesting-data/opentelemetry) pour découvrir les approches de déploiement en production.