Wazuh agent’ın **Active** görünmesi, beklediğiniz logun toplandığını veya dashboard’da alarm olarak gösterileceğini kanıtlamaz. Bağlantı kurulmuş olabilir; ancak yanlış kaynak izleniyor, olay bir kuralla eşleşmiyor, alarm eşiğinin altında kalıyor veya indeksleme aşamasında sorun yaşanıyor olabilir.

Bu yüzden ilk adım bütün servisleri yeniden başlatmak değil, **tek bir yeni olayı kaynağından dashboard’a kadar takip etmektir.**

## Önce sorunun hangi aşamada olduğunu belirleyin

Standart alarm akışı şöyledir:

```text
Kaynak log
  → Agent / Logcollector
  → Manager / decoder ve kurallar
  → alerts.json
  → Filebeat
  → Wazuh Indexer
  → Dashboard
```

[Resmî alarm yönetimi belgesine göre](https://documentation.wazuh.com/current/user-manual/manager/alert-management.html), üretilen alarmlar varsayılan olarak `alerts.json` dosyasına yazılır ve Filebeat tarafından indeksleyiciye aktarılır.

| Gözlem | Öncelikle incelenecek yer |
|---|---|
| Olay kaynak sistemde yok | Uygulama veya işletim sistemi log üretimi |
| Kaynakta var, agent’ın okuduğu belirsiz | `localfile`, journal filtreleri, izinler, merkezi yapılandırma |
| Manager arşivinde var, alarm yok | Decoder, kurallar, eşik ve bastırma koşulları |
| `alerts.json` içinde var, indekste yok | Filebeat, bağlantı, yetki ve indeksleme hataları |
| İndekste var, dashboard’da yok | Zaman aralığı, indeks deseni, filtreler ve kullanıcı yetkileri |

**Arşivleme kapalıysa `archives.json` dosyasının bulunmaması, olayın Manager’a ulaşmadığını göstermez.**

Başlamadan önce agent kimliğini, olay saatini ve ilgili makineyi not edin. Dağıtık kurulumda olayı işleyen Manager düğümünü belirleyin. Log örneklerindeki kullanıcı, müşteri ve gizli bilgileri dışarıya paylaşmadan önce temizleyin.

## 1. Kaynak sistem gerçekten yeni log üretiyor mu?

**Kontrolün yapılacağı yer: İzlenen makine, yani agent’ın kurulu olduğu sistem.**

Önce Wazuh’tan bağımsız olarak beklenen olayın oluştuğunu doğrulayın. Örneğin SSH olayları için:

```bash
sudo journalctl -u ssh.service -u sshd.service --since "15 minutes ago" --no-pager -o short-iso
```

Beklenen sonuç, araştırdığınız zaman aralığındaki gerçek SSH kayıtlarıdır. Çıktı yoksa hemen Wazuh’u suçlamayın: hizmet farklı bir birim adıyla çalışıyor veya farklı kaynağa yazıyor olabilir.

Dosya tabanlı loglama kullanılıyorsa dağıtım adından hareketle kesin yol varsaymayın:

| Ortam | Kontrol edilecek aday kaynak |
|---|---|
| Ubuntu/Debian, ilgili rsyslog yönlendirmesi mevcutsa | `/var/log/auth.log` |
| RHEL türevleri, ilgili authpriv yönlendirmesi mevcutsa | `/var/log/secure` |
| Journal tabanlı kurulum | `journalctl` çıktısı ve gerçek hizmet alanları |

Örneğin, **dosya mevcutsa**:

```bash
sudo tail -n 30 /var/log/auth.log
```

Kaynakta yeni kayıt yoksa önce uygulamanın log seviyesini ve log yönlendirmesini düzeltin. Var olmayan bir dosyayı agent yapılandırmasına eklemek çözüm değildir.

Ayrıca eski bir satırın bulunması, agent’ın onu yeniden okuyacağı anlamına gelmez. Wazuh’un [`only-future-events`](https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/localfile.html) davranışını dikkate alın; kontrol için yapılandırma uygulandıktan sonra oluşmuş **yeni bir olay** kullanın.

## 2. Agent doğru kaynağı topluyor mu?

**Kontrolün yapılacağı yer: Agent makinesi.**

Yerel yapılandırma dosyası:

```text
/var/ossec/etc/ossec.conf
```

Dosya tabanlı örnek, yalnız gerçekten bu dosyaya yazılan sistemler için anlamlıdır:

```xml
<localfile>
  <location>/var/log/auth.log</location>
  <log_format>syslog</log_format>
</localfile>
```

Journal kaynağında ise `location` ve `log_format` değerlerinin ikisi de `journald` olmalıdır. Şunları kontrol edin:

- Filtredeki hizmet adı gerçek journal kaydıyla uyuşuyor mu?
- `ssh.service` beklenirken kayıt `sshd.service` altında mı geliyor?
- Bir öncelik filtresi aradığınız olayı dışarıda mı bırakıyor?
- Dosya yolu, izinler veya rotasyon sonrası dosya durumu değişmiş mi?
- Aynı olay hem dosyadan hem journal’dan gereksiz yere toplanıyor mu?

**Önemli journal ayrıntısı:** Güncel [`localfile` belgesinde](https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/localfile.html), en az bir filtreli journald bloğu varsa filtresiz blokların yok sayıldığı belirtiliyor. Bu nedenle “bir tane de filtresiz blok ekleyeyim” yaklaşımı beklediğiniz sonucu vermeyebilir.

### Merkezi yapılandırmayı unutmayın

Agent bir gruptan yapılandırma alıyorsa yalnız yerel dosyaya bakmak yeterli değildir. Manager üzerindeki ilgili grubun `agent.conf` dosyasını da inceleyin.

[Merkezi yapılandırma belgesi](https://documentation.wazuh.com/current/user-manual/reference/centralized-configuration.html), yerel ve paylaşılan ayarların birleştirildiğini açıklar. Manager’da, örnek agent kimliğini kendi kimliğinizle değiştirerek senkronizasyonu kontrol edebilirsiniz:

```bash
sudo /var/ossec/bin/agent_groups -S -i 001
```

Beklenen sonuç grubun senkronize olmasıdır. Senkronizasyon, ayarın semantik olarak doğru olduğunu değil, dağıtıldığını gösterir.

### Değişiklik yapacaksanız

Önce değiştireceğiniz makinede yapılandırmanın yedeğini alın:

```bash
BACKUP="/var/ossec/etc/ossec.conf.before-logcheck.$(date +%Y%m%dT%H%M%S)"
sudo cp -a /var/ossec/etc/ossec.conf "$BACKUP"
```

Logcollector yapılandırmasını kontrol edin:

```bash
sudo /var/ossec/bin/wazuh-logcollector -t
```

Bu, [Logcollector yapılandırma testidir](https://documentation.wazuh.com/current/user-manual/reference/daemons/wazuh-logcollector.html); uçtan uca veri akışını doğrulamaz.

> Yerel ayarın uygulanması için agent’ı yeniden başlatacaksanız kısa izleme kesintisini planlayın. Hatalı yapılandırmayla devam etmeyin. Merkezi değişikliklerde ayrıca dağıtım ve yeniden yükleme durumunu kontrol edin.

```bash
sudo systemctl restart wazuh-agent
```

Ardından yeni bir kaynak olay oluşturup tekrar kontrol edin.

## 3. Bağlantı var mı; olay Manager’a ulaşıyor mu?

**Kontrolün yapılacağı yer: Manager.**

```bash
sudo /var/ossec/bin/agent_control -l
```

[`Active` durumu](https://documentation.wazuh.com/current/user-manual/reference/tools/agent-control.html) agent’ın Manager’a bağlı olduğunu belirtir. Ancak araştırdığınız kaynağın toplandığının kanıtı değildir.

İlgili agent ve Manager üzerindeki iç çalışma günlüklerini ayrı ayrı inceleyin:

```bash
sudo tail -n 100 /var/ossec/logs/ossec.log
```

Bu dosya uygulamanızın ham olay arşivi değil, Wazuh’un kendi çalışma günlüğüdür. Okuma, bağlantı, kimlik doğrulama ve kuyruk hataları açısından değerlendirin.

Agent bağlantısı gerçekten sorunluysa adres, port ve protokolü karşılaştırın. Güncel belgelerde varsayılan veri iletişimi **1514/TCP**, enrollment ise **1515/TCP** olarak ayrılır. Enrollment başarısı, veri kanalının sağlıklı olduğunun yerine geçmez. Sorunu çözmek için yönetim portlarını internete açmayın. [Kaynak](https://documentation.wazuh.com/current/user-manual/agent/agent-enrollment/troubleshooting.html)

### Gerekirse kısa süreli ham olay incelemesi

Her gelen olay alarm üretmediğinden, yalnız `alerts.json` dosyasında arama yapmak yeterli olmayabilir.

Wazuh arşivleri [varsayılan olarak kapalıdır](https://documentation.wazuh.com/current/user-manual/manager/event-logging.html). Arşivleme açıksa olayın ayırt edici metnini şu dosyada arayın:

```bash
sudo grep -F -- 'AYIRT_EDICI_METIN' /var/ossec/logs/archives/archives.json
```

Metni gerçek olaydan seçin; bulunan kaydın agent kimliğini ve zamanını da kontrol edin.

> **Risk:** `logall_json` yalnız seçtiğiniz agent’ı değil, ilgili Manager’ın aldığı olayları arşivleyebilir. Disk tüketimini ve hassas veri saklamayı artırır. Kapasite ve değişiklik onayı olmadan açmayın.

Geçici arşivleme gerekiyorsa:

1. Mevcut ayarı ve yapılandırma yedeğini kaydedin.
2. Boş alanı kontrol edin: `df -h /var/ossec`.
3. Mevcut `<global>` bölümündeki `logall_json` değerini geçici olarak değiştirin:

   ```xml
   <logall_json>yes</logall_json>
   ```

4. Manager’da yapılandırmayı kontrol edin:

   ```bash
   sudo /var/ossec/bin/wazuh-analysisd -t
   ```

5. **Planlı kısa kesinti kapsamında**, test başarılıysa Manager’ı yeniden başlatın:

   ```bash
   sudo systemctl restart wazuh-manager
   ```

6. Yeni olayı tekrar üretin, arşivde arayın ve disk büyümesini izleyin.
7. İnceleme bitince önceki ayara dönün; değişikliği yine kontrollü uygulayın.

Bu işlem arşivlerin dashboard’da otomatik görünmesini sağlamaz. Bunun için ayrıca arşiv indeksleme yapılandırması gerekir. Teşhis amacıyla bütün ham olayları indekslemek zorunda değilsiniz.

## 4. Olay neden alarm üretmiyor?

**Kontrolün yapılacağı yer: Manager.**

Manager’a ulaştığını doğruladığınız olayın gerçek log içeriğini kural motorunda inceleyin:

```bash
sudo /var/ossec/bin/wazuh-logtest
```

Arşivden alıyorsanız bütün JSON kaydını değil, olayın `full_log` içeriğini kullanın.

[Resmî test aracında](https://documentation.wazuh.com/current/user-manual/ruleset/testing.html) şu bilgileri arayın:

- Hangi decoder eşleşti?
- Beklenen alanlar ayrıştırıldı mı?
- Hangi kural eşleşti?
- Kuralın seviyesi ne?
- Kural tek olay mı, zaman içinde birden fazla olay mı bekliyor?

**`wazuh-logtest`, agent → Filebeat → dashboard hattının testi değildir.** Örnek bir metnin decoder ve kurallarla nasıl değerlendirildiğini gösterir.

Varsayılan [`log_alert_level` değeri 3’tür](https://documentation.wazuh.com/current/user-manual/manager/alert-management.html). Olayın bir kuralla eşleşmesi, mutlaka görünür alarm oluşturacağı anlamına gelmez. Eşik, bastırma ve korelasyon koşullarını birlikte değerlendirin.

Alarm üretmesi beklenen yeni olayı dosyada arayın:

```bash
sudo grep -F -- 'AYIRT_EDICI_METIN' /var/ossec/logs/alerts/alerts.json
```

Burada yoksa Filebeat’i düzeltmeye çalışmadan önce Manager aşamasında kalın.

Ayrıca [`jsonout_output`](https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/global.html) ayarını kontrol edin. Bu çıktı kapalıysa standart kurulumda Filebeat’in okuyacağı JSON alarm dosyası güncellenmez.

Özel kural gerekiyorsa paketle gelen kuralları doğrudan değiştirmeyin. [Yerel kural dosyalarını](https://documentation.wazuh.com/current/user-manual/ruleset/rules/custom.html) kullanın; hem eşleşmesi gereken hem eşleşmemesi gereken örnekleri test edin. Bütün logları görmek için genel alarm eşiğini düşünmeden düşürmeyin.

Ayarlar doğru görünmesine rağmen alarm üretimi durmuşsa disk, kuyruklar ve sürüm notları da araştırılmalıdır. Örneğin [4.14.8 sürüm notlarında](https://documentation.wazuh.com/current/release-notes/release-4-14-8.html), Active Response kuyruğu dolduğunda alarm üretimini durduran bir `analysisd` kilitlenmesinin düzeltildiği belirtilir. Bu, her benzer belirtinin aynı kök nedenden kaynaklandığını göstermez.

## 5. Alarm dosyada var, indekste yok mu?

**Kontrolün yapılacağı yer: Alarmı üreten Manager ile ilişkili Filebeat makinesi.**

```bash
sudo systemctl status filebeat --no-pager
sudo filebeat test output
sudo journalctl -u filebeat --since "15 minutes ago" --no-pager
```

[Wazuh’un dashboard sorun giderme belgesi](https://documentation.wazuh.com/current/user-manual/wazuh-dashboard/troubleshooting.html), `filebeat test output` kontrolünü önerir.

Beklenen sonuç bağlantı, TLS ve sunucuyla iletişim testlerinin başarılı olmasıdır. Başarısızsa:

- DNS veya bağlantı hatasında hedef adresi ve ağ erişimini;
- TLS hatasında CA zincirini, sertifika adını ve geçerliliğini;
- kimlik doğrulama/yetki hatasında ilgili servis hesabını;
- indeksleme hatasında disk, indeks ve kayıt işleme hatalarını inceleyin.

TLS doğrulamasını kapatmak veya servis hesaplarını varsayılan parolalara döndürmek kalıcı çözüm değildir.

**Bağlantı testinin başarılı olması da belirli alarmın indekslendiğini kanıtlamaz.** Filebeat’in doğru alarm dosyasını okuduğunu ve olayın gerçekten indekslendiğini ayrıca doğrulayın.

## 6. İndekste var ama dashboard’da görünmüyor mu?

**Kontrolün yapılacağı yer: Yetkili dashboard oturumu / Indexer sorgusu.**

Dev Tools erişiminiz varsa aşağıdaki salt okunur sorguyla başlayabilirsiniz. `001` ve `AYIRT_EDICI_METIN` değerlerini kendi olayınıza göre değiştirin:

```http
GET /wazuh-alerts-*/_search
{
  "size": 5,
  "query": {
    "bool": {
      "filter": [
        { "term": { "agent.id": "001" } },
        { "range": { "timestamp": { "gte": "now-30m" } } }
      ],
      "must": [
        { "match_phrase": { "full_log": "AYIRT_EDICI_METIN" } }
      ]
    }
  }
}
```

Bu örnek [OpenSearch Search API](https://docs.opensearch.org/latest/api-reference/search-apis/search/) yapısını kullanır. Olayınızda `full_log` saklanmıyorsa sorguyu mevcut alanlara uyarlayın.

Beklenen sonuç, ilgili olayın `hits.hits` içinde bulunmasıdır. Sonuç yoksa önce agent kimliğini, aranan metni ve zaman aralığını doğrulayın. Saat farkı veya hatalı filtreyi veri kaybı sanmayın.

Olay indekste bulunduğunda dashboard tarafında şunları kontrol edin:

- Alarm verileri için doğru indeks deseni seçili mi?
- Zaman aralığı olay saatini kapsıyor mu?
- Agent, kural seviyesi veya kayıtlı sorgu filtresi olayı dışlıyor mu?
- Kullanıcı ilgili indeksi okumaya yetkili mi?
- Doğru görünüm ve gerekiyorsa tenant seçili mi?

`wazuh-alerts-*` ile `wazuh-archives-*` aynı veri kümesi değildir. Alarm üretmeyen bir ham olayın alarm ekranında görünmesini beklemeyin.

Bu aşamada indeks silmek, yeniden indeksleme başlatmak veya güvenlik yapılandırmasını sıfırlamak ilk müdahale olmamalıdır.

## 7. Düzeltmeyi aynı olayla doğrulayın ve geçici ayarları geri alın

Başarı ölçütü yalnız servislerin `running` olması değildir.

**Alarm üretmesi beklenen, kontrollü ve yeni bir olay** için şu zinciri doğrulayın:

1. Kaynak sistemde oluştu.
2. Doğru agent ve kaynak üzerinden toplandı.
3. Beklenen decoder/kural tarafından işlendi.
4. Manager’ın `alerts.json` dosyasına yazıldı.
5. İndekste bulundu.
6. Yetkili kullanıcı tarafından dashboard’da görüntülendi.

Aynı olayın agent kimliğini, zamanını ve ayırt edici alanlarını aşamalar arasında karşılaştırın. Rastgele SSH parola denemeleri veya üretim servislerini durdurmak yerine, onaylı test makinesi ve güvenli bir test senaryosu kullanın.

İşlem sonunda:

- Geçici arşiv ayarını önceki durumuna döndürün.
- Eklediğiniz test kuralı ve kaynaklarını kontrollü kaldırın.
- Değişiklik başarısızsa ilgili yedeği geri yükleyip yapılandırmayı yeniden doğrulayın.
- Oluşan teşhis kayıtlarını kurumun saklama ve erişim politikasına göre yönetin.
- Bulguyu, yapılan değişikliği ve kabul testinin sonucunu kaydedin.

**Özet:** “Agent bağlı ama log gelmiyor” tek bir hata değildir. Kaynak logu, toplanan olayı, üretilen alarmı ve indekslenmiş kaydı ayrı ayrı kanıtladığınızda sorunun yeri daralır; gereksiz ve riskli değişikliklerden kaçınırsınız.

Kurumsal ortamınızda bu kontrolleri kaynak envanteri, kabul testleri ve işletim sorumluluklarıyla birlikte ele almak için [Mono’nun Wazuh kurulum ve operasyon desteğini](/teknolojiler/wazuh/) inceleyebilirsiniz.

### Kaynaklar

- [Wazuh — Log toplama yapılandırması](https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/localfile.html)
- [Wazuh — Olay arşivleme](https://documentation.wazuh.com/current/user-manual/manager/event-logging.html)
- [Wazuh — Alarm yönetimi](https://documentation.wazuh.com/current/user-manual/manager/alert-management.html)
- [Wazuh — Decoder ve kural testi](https://documentation.wazuh.com/current/user-manual/ruleset/testing.html)
- [Wazuh — Dashboard sorun giderme](https://documentation.wazuh.com/current/user-manual/wazuh-dashboard/troubleshooting.html)
- [Wazuh — 4.14.8 sürüm notları](https://documentation.wazuh.com/current/release-notes/release-4-14-8.html)