# Journaux

> logs, logs --follow

Un service tient **trois journaux**, gardés chez Arkya et non plus seulement en mémoire
sur le nœud.

| Flux | Ce qu'il contient | Quand il est écrit |
| --- | --- | --- |
| service | Ce que le processus écrit | en continu, et pendant chaque mise en service |
| construction | La sortie de `docker build` | à chaque `ark build` / `ark deploy` |
| mise en service | Les étapes du déploiement | à chaque `ark deploy` |

Chacun garde ses **10 000 dernières lignes** : au-delà, les plus anciennes sont écrasées.
Les journaux de construction et de mise en service sont **remplacés** à chaque
déploiement — tu lis toujours le dernier, pas un empilement.

## ark logs

Les dernières lignes écrites par le service, même s'il est arrêté **ou s'il a planté**.

```bash
ark logs survie-2026
ark logs survie-2026 --lines 40
ark logs survie-2026 --build
ark logs survie-2026 --deploy
```

```
[13:02:11 INFO]: Starting minecraft server version 1.21.4
[13:02:26 INFO]: Done (14.902s)! For help, type "help"
[13:04:02 INFO]: zoe joined the game
```

| Option | Défaut | Ce qu'elle fait |
| --- | --- | --- |
| `--lines` | 100 | Combien de lignes remonter. |
| `--follow` | — | Reste attaché et affiche la suite au fil de l'eau. |
| `--build` | — | Le journal de la dernière construction d'image. |
| `--deploy` | — | Les étapes de la dernière mise en service. |

<Note>
  `--follow` ne vaut que pour le journal du service : les deux autres sont clos une fois
  terminés.
</Note>

## Quand ça plante au démarrage

C'est le cas qui fait perdre le plus de temps ailleurs : l'application sort en erreur,
le conteneur disparaît, et le journal avec lui. Chez nous, ce que le service a écrit
avant de s'arrêter est **gardé**, et remonté directement dans l'erreur de déploiement :

```
- mise en service de mon-api:8f2c1d9a
x mon-api n'est pas repartie — voici ce qu'elle a écrit avant de s'arrêter :
Error: connect ECONNREFUSED 10.0.1.4:5432
    at TCPConnectWrap.afterConnect
```

Et il reste lisible après coup :

```bash
ark logs mon-api            # ce que le service a écrit
ark logs mon-api --deploy   # les étapes, avec l'horodatage de chacune
```

```
21:16:27 mise en service de 8f2c1d9a
21:16:27 adresse 51.210.44.12:30018
21:16:27 remplacement du conteneur
21:17:48 mon-api n'est pas repartie
```

<Warning>
  Une application qui meurt en moins d'une seconde peut perdre ses toutes dernières
  lignes : le nœud coupe le flux en même temps que le processus. Le gros du démarrage
  est là, mais pas toujours l'ultime ligne de `stderr`.
</Warning>

## Suivre en direct

```bash
ark logs survie-2026 --follow
```

```
— en direct, Ctrl+C pour sortir
[13:06:40 INFO]: marc joined the game
[13:07:02 INFO]: nils left the game
```

`--follow` passe par le même lien que [la console](/cli/console), mais en lecture
seule : tu ne peux rien envoyer. Pour parler au processus, c'est `ark console`.

<Note>
  Avec `--follow`, le CLI n'affiche pas d'abord les cent dernières lignes : le flux
  en direct rejoue déjà le tampon du serveur, et tu les verrais deux fois.
</Note>

## Dans un script

```bash
ark logs api-boutique --lines 100 | grep -i "error"
```

La sortie n'est pas colorée quand elle n'est pas lue par un terminal : tu peux la
passer à `grep`, `awk` ou un fichier sans t'occuper des codes d'échappement.

## Dans l'espace client

L'onglet **Journaux** d'un service montre les mêmes trois flux, avec un sélecteur
Service / Construction / Mise en service.

## Les journaux d'une application

Pour une application conteneurisée, ce sont les lignes de ton processus — ce que tu
écris sur la sortie standard et sur la sortie d'erreur.

```bash
cd mon-projet
ark logs --follow
```

Dans un dossier qui porte un `arkya.json`, inutile de nommer le service.

## Ce qui n'existe pas

Il n'y a **pas de journal des requêtes HTTP**. Tes services sont publiés en direct sur
un port du nœud, sans proxy devant : rien n'observe le trafic. Ça viendra avec un
ingress, pas avant.