# آموزش نصب و راه‌اندازی Splunk Enterprise؛ مدیریت متمرکز لاگ در سازمان

نصب Splunk Enterprise و Universal Forwarder روی Linux و Windows؛ TLS، Index و Retention، جست‌وجوی SPL، کلاستر، ظرفیت و عیب‌یابی عملیاتی.

## رخداد ثبت شده؛ تیم عملیات می‌تواند آن را پیدا کند؟

خطای ورود روی Windows Server، تلاش SSH روی Ubuntu و Deny فایروال ممکن است به یک رخداد مربوط باشند. وقتی ساعت، نام میزبان و زمان نگهداری آن‌ها یکسان نیست، قرارگرفتنشان در یک صفحه به‌تنهایی توالی قابل اعتماد نمی‌سازد. پیش از نصب Splunk مشخص کنید کدام رخداد باید از قطعی جان سالم ببرد، چه کسی اجازه جست‌وجوی آن را دارد و پاسخ تحلیل‌گر چقدر می‌تواند منتظر بماند.

مبنای دستورها Splunk Enterprise و Universal Forwarder نسخه 10.2.9 با Build برابر 41bebfa38eb4 روی Ubuntu Server 24.04 LTS و معماری amd64 است. بسته‌های این نسخه در کاتالوگ رسمی وجود دارند و طبق سیاست منتشرشده، شاخه 10.2 تا ژانویه ۲۰۲۸ پشتیبانی می‌شود. این مبنا برای تکرارپذیری انتخاب شده و ادعای جدیدترین انتشار نیست؛ پیش از استفاده، Security Advisory و سازگاری Add-onها را بررسی کنید. فرمان‌ها و تنظیمات با مستندات تطبیق داده شده‌اند؛ اجرای واقعی یا Load Test روی زیرساخت Splunk انجام نشده است.

[سیاست رسمی پشتیبانی Splunk](https://www.splunk.com/en_us/legal/splunk-software-support-policy.html)

## مسیر داده را از مدیریت جدا کنید

![معماری توزیع‌شده Splunk؛ مسیر Forwarding، Indexing و Search با نقش‌های مدیریتی جدا](/assets/img/articles/content/splunk-enterprise-installation-guide/distributed.svg)

Splunk Enterprise نرم‌افزاری است که نقش Indexer، Search Head، Heavy Forwarder و چند نقش مدیریتی را اجرا می‌کند. Indexer جریان ورودی را پردازش و به Bucket قابل جست‌وجو تبدیل می‌کند و سهم خود از Search توزیع‌شده را اجرا می‌کند. Search Head درخواست SPL را می‌گیرد، کار را توزیع و نتیجه‌ها را ادغام می‌کند. Universal Forwarder عامل سبک جمع‌آوری است؛ فایل و ورودی‌های پشتیبانی‌شده سیستم‌عامل را می‌خواند، اما موتور کامل Index و Search ندارد. Heavy Forwarder وقتی توجیه دارد که Input، Routing یا تبدیل هنگام Indexing به Pipeline کامل نیاز داشته باشد؛ لازم نیست تمام منابع را بی‌دلیل از یک Hop اضافی عبور دهید.

Deployment Server برنامه‌های تنظیماتی را با Server Class میان Forwarderهای مشخص توزیع می‌کند؛ مسئول Load Balancing داده یا Replicaهای Index نیست. Cluster Manager فعالیت Indexer Peerها و نسخه‌های Bucket را هماهنگ می‌کند. License Manager مجوز و مصرف گزارش‌شده Peerها را کنترل می‌کند و ظرفیت دیسک اضافه نمی‌کند. Monitoring Console سلامت عملیات را نشان می‌دهد. Search Head Cluster برای توزیع App به Deployer هم نیاز دارد؛ Deployer و Deployment Server وظیفه یکسان ندارند.

Splunk Enterprise با Splunk Cloud Platform، که زیرساخت آن به‌صورت سرویس اداره می‌شود، متفاوت است. Enterprise Security یا ES راهکار امنیتی با مجوز، سازگاری و نیازمندی منابع مستقل است. نصب Enterprise به معنای نصب ES، محتوای Correlation و فرایند عملیاتی SOC نیست. Searchهای این راهنما قابلیت عملیاتی Enterprise را نشان می‌دهند و به ES نسبت داده نمی‌شوند.

## کوچک‌ترین معماری سازگار با نیاز بازیابی را انتخاب کنید

| مدل | اجزا و محدودیت |
| --- | --- |
| آزمایشگاه | یک Enterprise و یک UF؛ داده آزمایشی و بدون تعهد دسترس‌پذیری. |
| Production کوچک | Enterprise مستقل، Forwarder با TLS، Backup بیرونی و مانیتورینگ؛ خرابی سرور، Ingest و Search را متوقف می‌کند. |
| توزیع‌شده | Search Head و Indexerهای جدا؛ Deployment Server در صورت نیاز به توزیع تنظیمات. چند Indexer مستقل داده را Replica نمی‌کنند. |
| Enterprise با HA | Indexer Cluster با Manager و حداقل سه Peer برای RF=3؛ Search Head Cluster با حداقل سه عضو، Deployer و Load Balancer دسترسی کاربران. دامنه‌های خرابی و برنامه بازیابی باید مستقل باشند. |

نصب زیر یک Receiver مستقل و امن می‌سازد؛ برای Pilot و Production کوچک زمانی مناسب است که زمان بازیابی همان سرور پذیرفته شده باشد. فصل Cluster مسیر توسعه جداگانه را توضیح می‌دهد. سه VM روی یک ESXi و یک Datastore، تحمل خرابی Host یا Storage ایجاد نمی‌کنند. برای شعب، Collector دارای Buffer دیسکی را نزدیک تجهیزات بگذارید، Timestamp را حفظ کنید و حجم Backlog در قطعی WAN را محاسبه کنید.

## سیستم‌عامل و مسیر Storage را آماده کنید

نسخه منتخب از Ubuntu 24.04 و 22.04 در معماری x86-64 و توزیع‌های جدول پشتیبانی حمایت می‌کند. تمام مراحل این متن روی Ubuntu 24.04 است؛ سرور Enterprise را نصب ARM فرض نکنید. نیازمندی Instruction Set پردازنده، از جمله الزامات KV Store، باید با CPU ارائه‌شده به VM سازگار باشد. برای Lab کوچک می‌توان از 4 vCPU و 8 GB RAM شروع کرد، اما این مشخصات مرجع Production سازنده نیست. مرجع منتشرشده برای نصب مستقل Production، تعداد ۱۲ هسته فیزیکی یا 24 vCPU و 12 GB RAM را ذکر می‌کند؛ Search هم‌زمان و ES ممکن است منابع بسیار بیشتری بخواهند. منابع را رزرو کنید و vCPU دارای Overcommit را هم‌ارز هسته فیزیکی نگیرید.

[سیستم‌عامل‌ها و پیش‌نیازهای رسمی شاخه 10.2](https://help.splunk.com/en/splunk-enterprise/administer/install-and-upgrade/10.2/plan-your-splunk-enterprise-installation/system-requirements-for-use-of-splunk-enterprise-on-premises)

[سخت‌افزار مرجع Splunk برای هر نقش](https://help.splunk.com/?resourceId=Splunk_Capacity_Referencehardware)

نام DNS ثابت، Resolve قابل اعتماد، ساعت هماهنگ با UTC، Storage کم‌تأخیر و Filesystem مستقل برای داده Index فراهم کنید. بار Hot/Warm به IOPS و Latency اندازه‌گیری‌شده هنگام Read/Write هم‌زمان نیاز دارد؛ NAS حجیم ولی کند مسئله ظرفیت را حل نمی‌کند. XFS یا ext4 روی Block Storage یا دیسک محلی محافظت‌شده نقطه شروع عملی است، به شرط تطبیق با ماتریس پشتیبانی Filesystem. Encryption at Rest و پایش فضای آزاد، Inode و تأخیر دیسک را در نظر بگیرید. Mountها باید پیش از شروع Splunk حاضر باشند.

| پورت | مسیر مجاز |
| --- | --- |
| 8000/TCP | پس از تنظیم، HTTPS برای Splunk Web؛ فقط شبکه کاربران مجاز یا VPN. |
| 8089/TCP | API مدیریت با TLS؛ فقط ادمین، Deployment Client و Peerهای مرتبط. |
| 9997/TCP | Receiver با TLS در این راهنما؛ فقط شبکه Forwarder. خودکار فعال نیست. |
| 9887/TCP | نمونه پورت Replication برای Indexer؛ باید صریح تنظیم و میان Peerها محدود شود. |
| 8191/TCP | ارتباط KV Store مطابق توپولوژی؛ پورت عمومی کلاینت نیست. |
| 8065/TCP | نمونه پورت Replication انتخابی SHC؛ فقط میان اعضا. |
| 6514/TCP or approved syslog port | تجهیز به Collector با TLS در صورت پشتیبانی؛ UDP 514 فقط در Segment محافظت‌شده و با پذیرش احتمال اتلاف. |

```bash
hostnamectl
getent hosts splunk01.example.net
timedatectl status
lsblk -f
df -hT /opt /srv/splunk
df -i /srv/splunk
ss -lnt
sudo apt-get update
sudo apt-get install -y ca-certificates curl openssl acl sysstat rsyslog
```

این‌ها دستورهای بررسی‌اند و خروجی موفق ساختگی ندارند. همگام‌سازی ساعت، Filesystem مسیر داده و آزادبودن پورت‌ها را تأیید کنید. نام‌های example.net، شبکه‌ها و تمام Placeholderهای بزرگ را پیش از اجرا جایگزین کنید. قبل از محدودکردن Firewall از راه دور، مسیر دسترسی مدیریت را نگه دارید؛ 8089 را برای اینترنت باز نکنید.

## رسانه معتبر نصب کنید و Administrator را تعاملی بسازید

بسته tar لینوکس amd64 و فایل SHA512 متناظر را با حساب مجاز از کاتالوگ رسمی Enterprise بگیرید. کاتالوگ فرمان دانلود دقیق می‌دهد؛ URL را با حدس Build نسازید. بسته را با نام زیر ذخیره کنید و Checksum را جدا از سایت رسمی و از مسیر معتبر دریافت کنید. نام فایل داخل Checksum را کنترل کنید؛ Hash گرفته‌شده از Mirror ناشناس، اصالت بسته را اثبات نمی‌کند.

[بسته‌های رسمی Enterprise، نام Build و SHA512](https://www.splunk.com/en_us/download/previous-releases.html)

```bash
cd /var/tmp
sha512sum -c splunk-10.2.9-41bebfa38eb4-linux-amd64.tgz.sha512
# Continue only after the matching file reports OK.
sudo groupadd --system splunk
sudo useradd --system --gid splunk --home-dir /opt/splunk --shell /bin/bash splunk
sudo tar -xzf splunk-10.2.9-41bebfa38eb4-linux-amd64.tgz -C /opt
sudo chown -R splunk:splunk /opt/splunk
sudo install -d -o splunk -g splunk -m 0750 /srv/splunk/hotwarm /srv/splunk/cold /srv/splunk/thawed
sudo -u splunk /opt/splunk/bin/splunk start --accept-license
```

بلوک ساخت حساب برای Host تازه است؛ اگر حساب وجود دارد، مشخصاتش را بررسی کنید و هویت دوم نسازید. اولین Start نام Administrator و گذرواژه را تعاملی می‌پرسد. گذرواژه مستقل را از Vault سازمان وارد کنید؛ از -auth user:password در خط فرمان، Password مشترک داخل Git و ذخیره آن در History خودداری کنید. در این مرحله 8000 همچنان باید با Firewall شبکه محدود باشد؛ پیش از استفاده Web از شبکه، HTTPS را تنظیم کنید.

```bash
sudo -u splunk /opt/splunk/bin/splunk stop
sudo /opt/splunk/bin/splunk enable boot-start -systemd-managed 1 -user splunk -group splunk
sudo systemctl daemon-reload
systemctl list-unit-files '*splunk*' '*Splunk*'
sudo systemctl cat Splunkd.service
```

در نصب تازه با tar، نام سرویس معمولاً Splunkd.service است؛ نام واقعی تولیدشده را بررسی کنید و اگر فرق داشت، در دستورهای بعدی همان را بنویسید. Limitها را با Drop-in در systemd تنظیم کنید، نه با تغییر Unit تولیدشده. برای شروع می‌توان در بخش [Service] مقدار LimitNOFILE=65536 و LimitNPROC=16000 گذاشت، systemd را Reload کرد و مقدار مؤثر را با systemctl show دید. این‌ها تنظیم آغازین هستند و ظرفیت را ثابت نمی‌کنند. راهنمای Linux Tuning مربوط به همین انتشار، از جمله THP و حافظه، باید جدا اعمال شود؛ اسکریپت عمومی قدیمی Kernel را بدون بررسی روی انتشار جدید اجرا نکنید.

```bash
sudo systemctl edit Splunkd.service
# Enter the following drop-in, then save:
# [Service]
# LimitNOFILE=65536
# LimitNPROC=16000
sudo systemctl daemon-reload
sudo systemctl show Splunkd.service -p User -p Group -p LimitNOFILE -p LimitNPROC
```

[روش رسمی boot-start با systemd و بررسی نام Unit](https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/9.2/start-splunk-enterprise-and-perform-initial-tasks/run-splunk-enterprise-as-a-systemd-service)

## پیش از بازکردن Receiver، اعتماد TLS را برقرار کنید

از PKI سازمان Certificate با serverAuth برای نام DNS هر Splunk و clientAuth برای Forwarderهای دارای mTLS بگیرید. SAN سرور باید دقیقاً نامی را داشته باشد که Client استفاده می‌کند. کلید خصوصی CA را وارد Splunk نکنید. در این مثال PKI فایل‌های leaf.pem، issuer-chain.pem و server.key متناظر را تحویل داده است. PEM مربوط Receiver شامل Certificate سرور، کلید خصوصی و Chain صادرکننده است؛ ca-chain.pem جداگانه نیز CAهای مورد اعتماد را دارد. کلید سرویس بدون Passphrase با مالکیت محدود، Backup کنترل‌شده و رمزگذاری دیسک محافظت می‌شود؛ کلید رمزدار به فرایند حفاظت از sslPassword نیاز دارد.

```bash
sudo install -d -o splunk -g splunk -m 0700 /opt/splunk/etc/auth/enterprise
sudo install -o splunk -g splunk -m 0600 server.key /opt/splunk/etc/auth/enterprise/server.key
sudo install -o splunk -g splunk -m 0640 leaf.pem /opt/splunk/etc/auth/enterprise/web-chain.pem
sudo sh -c 'cat issuer-chain.pem >> /opt/splunk/etc/auth/enterprise/web-chain.pem'
sudo sh -c 'cat leaf.pem server.key issuer-chain.pem > /opt/splunk/etc/auth/enterprise/server.pem'
sudo chown splunk:splunk /opt/splunk/etc/auth/enterprise/server.pem
sudo chmod 0600 /opt/splunk/etc/auth/enterprise/server.pem
sudo install -o splunk -g splunk -m 0640 ca-chain.pem /opt/splunk/etc/auth/enterprise/ca-chain.pem
openssl x509 -in leaf.pem -noout -subject -issuer -dates -ext subjectAltName
sudo install -d -o splunk -g splunk -m 0750 /opt/splunk/etc/apps/meetaj_receiver/local
```

فایل‌های زیر را در App مشخص‌شده با مالکیت splunk:splunk و Mode برابر 0640 بسازید. etc/system/default را ویرایش نکنید. این Receiver به Client Certificate از CA مجاز نیاز دارد؛ Forwarder فاقد آن باید رد شود. CA صادرکننده اختصاصی برای Forwarder بهتر از اعتماد بی‌قید به تمام Certificateهای کلاینت زیر Root عمومی سازمان است.

### فایل meetaj_receiver/local/server.conf

```ini
[sslConfig]
sslRootCAPath = /opt/splunk/etc/auth/enterprise/ca-chain.pem
serverCert = /opt/splunk/etc/auth/enterprise/server.pem
sslVersions = tls1.2
sslVerifyServerCert = true
sslVerifyServerName = true
```

### فایل meetaj_receiver/local/inputs.conf

```ini
[splunktcp-ssl:9997]
disabled = 0

[SSL]
serverCert = /opt/splunk/etc/auth/enterprise/server.pem
requireClientCert = true
sslVersions = tls1.2
```

### فایل meetaj_receiver/local/web.conf

```ini
[settings]
enableSplunkWebSSL = true
httpport = 8000
privKeyPath = /opt/splunk/etc/auth/enterprise/server.key
serverCert = /opt/splunk/etc/auth/enterprise/web-chain.pem
```

TLS 1.2 مبنای صریح مثال‌های S2S است و به معنای پشتیبانی‌نشدن TLS 1.3 نیست. فعال‌سازی 1.3 به تنظیم Cipher و Group مستند و بررسی سازگاری تمام Peerها نیاز دارد. امن‌شدن 9997 به‌خودی‌خود Web، پورت 8089، KV Store و Replication کلاستر را امن نمی‌کند؛ هر مسیر تنظیم و آزمون پذیرش مستقل دارد. اعتبارسنجی ارتباط خروجی مدیریت، Peer دارای Certificate پیش‌فرض را آشکار می‌کند؛ پیش از افزودن Peer، Certificate آن را اصلاح کنید.

```bash
sudo -u splunk /opt/splunk/bin/splunk btool check
sudo -u splunk /opt/splunk/bin/splunk btool inputs list --debug
sudo -u splunk /opt/splunk/bin/splunk btool server list sslConfig --debug
sudo systemctl start Splunkd.service
sudo systemctl status Splunkd.service --no-pager
openssl s_client -connect splunk01.example.net:8000 -servername splunk01.example.net -CAfile ca-chain.pem -verify_hostname splunk01.example.net -verify_return_error </dev/null
curl --cacert ca-chain.pem -I https://splunk01.example.net:8000
```

btool check باید بدون خطای تنظیمات تمام شود؛ --debug نشان می‌دهد هر مقدار مؤثر از کدام فایل آمده است. آزمون TLS باید Chain و Hostname را معتبر بداند؛ Redirect HTTP به Login طبیعی است. پورت 9997 را دوباره با Certificate و کلید Client مجاز بررسی کنید و ردشدن Client بدون Certificate را هم بسنجید. پس از این کنترل، فقط Subnetهای Forwarder را به 9997 و کاربران مجاز را به 8000 راه دهید.

[تنظیم رسمی TLS برای دریافت و ارسال در 10.2](https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/secure-splunk-platform-communications-with-transport-layer-security-certificates/configure-splunk-indexing-and-forwarding-to-use-tls-certificates)

## پیش از ارسال Forwarder، Index مقصد را بسازید

Index مرز Storage و دسترسی است؛ sourcetype قالب رخداد، host مبدأ رخداد و source هویت فایل یا Input را مشخص می‌کند. برای هر سرور Index جدا نسازید. تفکیک وقتی ارزش دارد که دسترسی، Retention یا مالکیت عملیات فرق کند. Pilot را با infra آغاز کنید و Index امنیتی جدا را پس از تعیین سیاست دسترسی و نگهداری بسازید. مثال مستقل زیر نگهداری تا ۳۰ روز و سقف حدود 2 TiB برای این Index دارد. سقف حجمی صرفاً محافظ ظرفیت در این مثال است و ۳۰ روز نگهداری را تضمین نمی‌کند.

### فایل meetaj_receiver/local/indexes.conf؛ فقط نصب مستقل

```ini
[infra]
homePath = /srv/splunk/hotwarm/infra/db
coldPath = /srv/splunk/cold/infra/colddb
thawedPath = /srv/splunk/thawed/infra/thaweddb
frozenTimePeriodInSecs = 2592000
maxTotalDataSizeMB = 2097152
```

Hot Bucket در حال دریافت داده است. پس از Roll، به Warm قابل جست‌وجو تبدیل می‌شود؛ Cold نیز قابل جست‌وجو است و می‌تواند مسیر Storage دیگری داشته باشد. Frozen به‌طور پیش‌فرض حذف می‌شود؛ آرشیو خودکار فرض نکنید. coldToFrozenDir یا coldToFrozenScript را پس از اثبات موفقیت آرشیو، ظرفیت و روش Restore تنظیم کنید. Thawed داده آرشیوی بازیابی‌شده را نگه می‌دارد و سیاست پاک‌سازی جدا می‌خواهد. خروج بر اساس عمر، زمان رخدادهای Bucket را ارزیابی می‌کند، ولی سقف حجم می‌تواند داده را زودتر خارج کند. Timestamp آینده و بازه زمانی بسیار گسترده Bucket، برداشت شما از Retention را به‌هم می‌زند.

```bash
sudo -u splunk /opt/splunk/bin/splunk btool indexes list infra --debug
sudo systemctl restart Splunkd.service
```

[مرجع indexes.conf برای Retention، سقف حجم و Frozen](https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.2/configuration-file-reference/10.2.0-configuration-file-reference/indexes.conf)

## ابتدا یک Ubuntu و سپس Windows را متصل کنید

![Forwarder ورودی مجاز را می‌خواند، هویت Receiver را بررسی و رخداد را با mTLS ارسال می‌کند](/assets/img/articles/content/splunk-enterprise-installation-guide/forwarding.svg)

روی Ubuntu جداگانه، بسته tar ‏UF نسخه 10.2.9 برای amd64 و SHA512 آن را از کاتالوگ رسمی Forwarder بگیرید و پیش از Extract بررسی کنید. حساب غیر root به نام splunkfwd فقط به لاگ‌های لازم دسترسی خواندن می‌گیرد؛ برای دورزدن ACL آن را root نکنید. Add-on مربوط System/Unix را پس از بررسی سازگاری نسخه، Inputهای پیش‌فرض و Privilegeهای لازم نصب کنید.

[بسته و Checksum رسمی Universal Forwarder](https://www.splunk.com/en_us/download/previous-releases-universal-forwarder.html)

```bash
cd /var/tmp
sha512sum -c splunkforwarder-10.2.9-41bebfa38eb4-linux-amd64.tgz.sha512
sudo groupadd --system splunkfwd
sudo useradd --system --gid splunkfwd --home-dir /opt/splunkforwarder --shell /bin/bash splunkfwd
sudo tar -xzf splunkforwarder-10.2.9-41bebfa38eb4-linux-amd64.tgz -C /opt
sudo chown -R splunkfwd:splunkfwd /opt/splunkforwarder
sudo install -d -o splunkfwd -g splunkfwd -m 0750 /opt/splunkforwarder/etc/apps/meetaj_forwarding/local
sudo install -d -o splunkfwd -g splunkfwd -m 0700 /opt/splunkforwarder/etc/auth/enterprise
sudo -u splunkfwd /opt/splunkforwarder/bin/splunk start --accept-license
sudo -u splunkfwd /opt/splunkforwarder/bin/splunk stop
```

Administrator محلی UF را نیز تعاملی بسازید. فایل ترکیبی و یکتای client.pem و ca-chain.pem مورد اعتماد را در etc/auth/enterprise با مالکیت splunkfwd بگذارید؛ PEM دارای کلید خصوصی باید Mode برابر 0600 داشته باشد. مثال ارسال یک Receiver مستقل دارد. برای دو Receiver مستقل یا Peerهای Cluster، هر دو DNS:9997 را اضافه کنید، بررسی Hostname را نگه دارید و برای هر Receiver، SAN متناظر صادر کنید.

### فایل server.conf در App مربوط UF

```ini
[sslConfig]
sslRootCAPath = /opt/splunkforwarder/etc/auth/enterprise/ca-chain.pem
sslVerifyServerCert = true
sslVerifyServerName = true
```

### فایل outputs.conf در App مربوط UF

```ini
[tcpout]
defaultGroup = enterprise_indexers

[tcpout:enterprise_indexers]
server = splunk01.example.net:9997
useACK = true
clientCert = /opt/splunkforwarder/etc/auth/enterprise/client.pem
sslVerifyServerCert = true
sslVerifyServerName = true
sslVersions = tls1.2
```

### فایل inputs.conf در App مربوط UF

```ini
[monitor:///var/log/auth.log]
disabled = 0
index = infra
sourcetype = linux_secure

[monitor:///var/log/nginx/access.log]
disabled = 0
index = infra
sourcetype = nginx:access
```

وجود auth.log را بررسی کنید؛ Ubuntu دارای journald بدون فایل، ابتدا به مسیر جمع‌آوری Journal پشتیبانی‌شده یا ذخیره‌سازی rsyslog نیاز دارد. sourcetype برابر nginx:access به Knowledge مربوط Add-on یا تعریف props/transforms خودتان در لایه درست Parsing و Search احتیاج دارد؛ نوشتن نام، Parser را نصب نمی‌کند. روی فایل‌های موجود ACL بدهید و Default ACL یا قاعده create در logrotate را برای همان پوشه تنظیم کنید تا فایل تازه بعد از Rotation هم خوانده شود. با sudo -u splunkfwd test -r FILE دسترسی را بسنجید؛ بدون نیاز، کل /var/log را باز نکنید.

```bash
sudo -u splunkfwd test -r /var/log/auth.log
sudo -u splunkfwd /opt/splunkforwarder/bin/splunk btool check
sudo /opt/splunkforwarder/bin/splunk enable boot-start -systemd-managed 1 -user splunkfwd -group splunkfwd
systemctl list-unit-files '*splunk*' '*Splunk*'
# Use the generated UF unit name reported above:
sudo systemctl start SplunkForwarder.service
sudo -u splunkfwd /opt/splunkforwarder/bin/splunk list forward-server
logger -p auth.notice 'MEETAJ_SPLUNK_ACCEPTANCE ubuntu-forwarder'
```

نام Unit مربوط UF به Package و سابقه نصب وابسته است؛ اگر خروجی نام دیگری نشان داد، SplunkForwarder.service را جایگزین کنید. list forward-server باید مقصد مورد انتظار را Active نشان دهد، اما Activeبودن به‌تنهایی تحویل لاگ را ثابت نمی‌کند. Marker پذیرش را در infra جست‌وجو و host، source، sourcetype و زمان رخداد را بررسی کنید. useACK تأیید Indexer را اضافه می‌کند و پس از قطعی ممکن است ارسال مجدد رخ دهد؛ Duplicate و نگهداری لاگ مبدأ را طراحی کنید و وعده Exactly-once یا Buffer نامحدود آفلاین ندهید.

[مرجع 10.2 برای ACK، فهرست مقصد و اعتبارسنجی نام TLS](https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.2/configuration-file-reference/10.2.0-configuration-file-reference/outputs.conf)

### Windows Server؛ MSI معتبر و هویت سرویس با حداقل دسترسی

MSI مربوط Windows x64 نسخه 10.2.9 و Checksum را از همان کاتالوگ رسمی بگیرید. در PowerShell با دسترسی Administrator، امضای Authenticode و Hash از نوع SHA512 را ببینید و MSI را تعاملی اجرا کنید. اگر مجوزها برای Input کافی است، Virtual Service Account را انتخاب و گذرواژه ادمین محلی را داخل Installer تنظیم کنید. حساب Domain Admin استفاده نکنید. خواندن Security Event به Privilege مناسب Windows نیاز دارد؛ Installer دسترسی‌های Virtual Account، از جمله SeBackupPrivilege، را مستند کرده است. آن‌ها را با تیم امنیت بررسی کنید و صرف نام Virtual را نشانه کم‌خطر بودن ندانید.

```powershell
$msi = Get-Item 'C:\Install\splunkforwarder-10.2.9-41bebfa38eb4-windows-x64.msi'
Get-AuthenticodeSignature -FilePath $msi.FullName | Format-List Status,SignerCertificate
Get-FileHash -Path $msi.FullName -Algorithm SHA512
# Compare the hash with the vendor SHA512 file before proceeding.
Start-Process msiexec.exe -ArgumentList @('/i', $msi.FullName) -Wait
Get-Service SplunkForwarder
```

App ارسال را در C:\Program Files\SplunkUniversalForwarder\etc\apps\meetaj_forwarding\local کپی کنید. مسیر Certificateهای server.conf و outputs.conf را برای Windows اصلاح کنید، CA و اعتبارسنجی Hostname را نگه دارید و ACL کلید خصوصی را به هویت سرویس و Administratorهای مجاز محدود کنید. inputs.conf زیر را بعد از ساخت infra و فعال‌بودن Security Auditing طبق Policy اضافه کنید. رخداد 4625 وقتی Windows آن را ثبت نمی‌کند قابل جمع‌آوری نیست.

```ini
[WinEventLog://Security]
disabled = 0
index = infra
renderXml = true

[WinEventLog://System]
disabled = 0
index = infra
renderXml = true

[WinEventLog://Application]
disabled = 0
index = infra
renderXml = true
```

```powershell
& 'C:\Program Files\SplunkUniversalForwarder\bin\splunk.exe' btool inputs list --debug
Restart-Service SplunkForwarder
& 'C:\Program Files\SplunkUniversalForwarder\bin\splunk.exe' list forward-server
Test-NetConnection splunk01.example.net -Port 9997
```

[Installer ویندوز و دسترسی Virtual Account؛ تطبیق با MSI منتخب](https://help.splunk.com/en/splunk-enterprise/forward-and-process-data/universal-forwarder-manual/10.6/install-the-universal-forwarder/install-a-windows-universal-forwarder)

## هر منبع را با قرارداد مشخص Parsing وارد کنید

| منبع | روش و محدودیت |
| --- | --- |
| Syslog لینوکس | UF فایل ذخیره‌شده را می‌خواند؛ Add-on مربوط Unix/Linux، Knowledge و اسکریپت‌های اختیاری دارد. Host دارای journald بدون فایل، روش جمع‌آوری مشخص می‌خواهد. |
| ویندوز | Input مربوط Event Log روی UF همراه Splunk Add-on for Microsoft Windows؛ اجزای Input و Search را در لایه مستند نصب و استخراج فیلد XML را کنترل کنید. |
| Nginx | UF فایل access/error را می‌خواند؛ log_format دقیق را با Add-on سازگار یا sourcetype بررسی‌شده تطبیق دهید. خطاهای چندخطی آزمون می‌خواهند. |
| سیسکو | Collector با صف پایدار، سپس مانیتور فایل با UF یا مسیر پشتیبانی‌شده SC4S؛ Add-on را مطابق IOS، ASA یا محصول واقعی انتخاب کنید، نه Parser فرضی مشترک سیسکو. |
| میکروتیک | Remote Logging در RouterOS به Collector؛ host و زمان اصلی حفظ شود. Add-on جامعه کاربری بررسی امنیت و سازگاری جدا می‌خواهد و ممکن است استخراج سفارشی لازم باشد. |
| VMware | Remote Syslog در ESXi برای لاگ است؛ Inventory و Performance از API مربوط vCenter به Add-on سازگار VMware، Collector پشتیبانی‌شده و Credential نیاز دارد. ESXi را Ubuntu فرض و UF روی آن نصب نکنید. |
| SQL Server | Application Log ویندوز و ERRORLOG یا Audit مجاز SQL جمع‌آوری می‌شود. Query با DB Connect به JDBC Driver، Runtime سازگار و حساب دیتابیس محدود نیاز دارد و به معنای Capture لاگ تراکنش نیست. |
| لاگ برنامه | فایل با UF یا HEC احراز هویت‌شده روی HTTPS؛ Timestamp در JSON، مرز رخداد و حذف Secret را تعریف کنید. HEC به تنظیم و Scope نیاز دارد؛ TCP عمومی بدون TLS جای آن نیست. |

Collector پایدار Syslog را از Restartهای Indexer مستقل نگه دارید. فایل تجهیزات را بر پایه Metadata معتبر فرستنده تفکیک کنید، نه فیلدی از Payload قابل جعل. فایل محلی را به اندازه پوشش قطعی نگه دارید و Drop صف را پایش کنید. رسیدن Packet از UDP به Collector معادل تأیید تحویل رخداد نیست. پیش از Search گسترده، با یک رخداد بی‌خطر و شناخته‌شده، Raw Data، Timezone، مرز خط و فیلدها را کنترل کنید. Add-onها ناشر و ماتریس پشتیبانی جدا دارند؛ Package بررسی‌نشده Splunkbase را روی تمام نقش‌ها نصب نکنید.

[Splunkbase؛ بررسی ناشر، سازگاری نسخه و لایه نصب](https://splunkbase.splunk.com/)

Transport در RouterOS به Format وابسته است: طبق مستند جاری MikroTik، ارسال TCP و TLS با CEF کار می‌کند و قالب syslog حتی با انتخاب Transport دیگر همچنان UDP است. قبل از انتخاب CEF، Build دقیق RouterOS و Parser مقصد را بررسی کنید. در ESXi، Remote Syslog را با تنظیم پشتیبانی‌شده Host فعال و Firewall خروجی، DNS و Parsing زمان UTC را تأیید کنید؛ Hypervisor را صرفاً برای شبیه‌شدن به Collector فایل لینوکس تغییر ندهید.

[قالب و محدودیت Transport در Logging مربوط RouterOS](https://help.mikrotik.com/docs/spaces/ROS/pages/328094/Log)

[Broadcom؛ تنظیم Remote Syslog در ESXi](https://knowledge.broadcom.com/external/article/318939/configuring-syslog-on-esxi.html)

[مسیرهای جمع‌آوری Add-on مربوط SQL Server؛ ‏DB Connect، Performance ویندوز و فایل](https://help.splunk.com/en/splunk-cloud-platform/get-data-in/splunk-supported-add-ons/splunk-supported-add-ons/microsoft-sql-server)

## رخدادی را جست‌وجو کنید که واقعاً جمع‌آوری می‌شود

Searchهای زیر از Index ساخته‌شده infra و بازه زمانی محدود استفاده می‌کنند. نام فیلد به Add-on و نوع Input وابسته است؛ آن را در یک Sample Event بررسی کنید. Search متن خام برای عیب‌یابی مفید است، اما Detection Rule کامل نیست. برای ES، نگاشت CIM و Data Model Acceleration را جدا تأیید کنید؛ صرفاً برای پرشدن Dashboard، نام فیلد خام را بی‌بررسی تغییر ندهید.

### ورود ناموفق SSH

```spl
index=infra sourcetype=linux_secure earliest=-15m latest=now "Failed password"
| rex "from (?<src_ip>\S+) port"
| stats count min(_time) as first_seen max(_time) as last_seen by host src_ip
| convert ctime(first_seen) ctime(last_seen)
| sort - count
```

این Search از پیام رایج OpenSSH آدرس مبدأ را استخراج و تعداد Failure را به تفکیک Host مقصد و مبدأ می‌شمارد. خطای Public Key و تفاوت‌های PAM به الگوهای اضافه نیاز دارند؛ آن را جست‌وجوی تمام خطاهای SSH معرفی نکنید.

### خطاهای احراز هویت Windows

[Microsoft؛ Audit Policy و پوشش رخداد احراز هویت](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/advanced-audit-policy-configuration)

```spl
index=infra earliest=-30m latest=now (sourcetype=WinEventLog:Security OR sourcetype=XmlWinEventLog:Security) EventCode=4625
| stats count values(Logon_Type) as logon_types by host Account_Name Source_Network_Address
| sort - count
```

EventCode و فیلدهای حساب و آدرس به Add-on سازگار Windows وابسته‌اند؛ نام فیلد در XML ممکن است فرق کند. ابتدا رخداد واقعی را باز کنید. خطاهای Kerberos دامین ممکن است جمع‌آوری 4771 و 4768 از Domain Controller بخواهند؛ 4625 تصویر کامل احراز هویت نیست.

### Deny فایروال و خطاهای تجهیزات

```spl
index=infra sourcetype=network:syslog earliest=-15m latest=now ("Deny" OR "denied" OR "DROP")
| stats count by host
| sort - count

index=infra sourcetype=network:syslog earliest=-1h latest=now ("LINK-3-UPDOWN" OR "ERR" OR "critical")
| table _time host _raw
| sort - _time
```

network:syslog در اینجا sourcetype سفارشی نمونه است و Add-on آماده فرض نمی‌شود؛ آن را با sourcetype واقعی جایگزین کنید. برای گزارش Production، Parser سازنده و فیلدهای action و severity تأییدشده را ترجیح دهید؛ وجود کلمه deny در تغییر Configuration الزاماً Packet ردشده نیست.

### Exception برنامه و الگوی ورود غیرعادی

```spl
index=infra sourcetype=app:json earliest=-30m latest=now
| spath
| search level=ERROR
| stats count values(exception.type) as exceptions by service.name host

index=infra earliest=-15m latest=now EventCode=4625
| stats count dc(Account_Name) as distinct_accounts values(Account_Name) as accounts by Source_Network_Address
| where count>=20 AND distinct_accounts>=5
| sort - count
```

مثال JSON وجود همین Keyها را فرض کرده است؛ Parsing و مرز رخداد app:json را پیش از استفاده تعریف کنید. Search دوم فقط نشانه نمونه Password Spraying است. تنظیم اشتباه Service Account، Gateway مشترک و خطای استخراج فیلد هم می‌توانند آن را فعال کنند. Exclusion، مراحل بررسی و مسئول رسیدگی را مشخص کنید؛ عبور از Threshold مدرک نفوذ نیست.

## Dashboard را حول سؤال عملیاتی بسازید

در Search & Reporting، Search دارای بازه محدود را با Owner و Scope مشخص App ذخیره کنید. پنل تعداد رخداد هر Host، تأخیر ورود، خطای احراز هویت و نرخ خطای تجهیزات بسازید. در Dashboard Studio، Time Range مشترک به پنل‌ها بدهید و معلوم کنید نمودار از زمان رخداد استفاده می‌کند یا زمان Index. منبعی که رخداد ندارد باید در پنل مستقل Missing Source دیده شود؛ Dashboard آرام ممکن است Collector خراب را پنهان کند.

```spl
index=infra earliest=-1h latest=now
| eval lag_seconds=_indextime-_time
| stats count perc95(lag_seconds) as p95_delay max(_time) as latest_event by host
| eval seconds_since_latest=now()-latest_event
| sort - p95_delay
```

برای Pilot، Alert هر پنج دقیقه با بازه ده دقیقه اخیر و هم‌پوشانی آگاهانه، تأخیر را بهتر پوشش می‌دهد. شرط اجرا را روی تعداد نتیجه یا Threshold بررسی‌شده بگذارید، Throttle را با کلید رخداد تنظیم کنید و فقط فیلد لازم را بفرستید. Owner زمان‌بندی‌شده باید دسترسی Index لازم و کمترین مجوز مدیریتی را داشته باشد. تحویل، Deduplication و وضعیت Owner پس از Disableشدن حساب را آزمایش کنید. مقصد Webhook را محدود و Token را محافظت کنید؛ Alert Action می‌تواند لاگ حساس را از پلتفرم خارج کند.

## خود پلتفرم را هم محدود کنید

روش احراز هویت سازمانی پشتیبانی‌شده را متصل، گروه‌ها را به Role نگاشت و Administrator اضطراری محلی را در Vault نگه دارید. اپراتور فقط Indexهای مجاز را ببیند؛ Wildcard ممکن است Index امنیتی تازه را هم ناخواسته در دسترس بگذارد. مدیریت Input، نصب App، مالکیت Search زمان‌بندی‌شده و بررسی امنیتی را از هم جدا کنید. App واردشده را کد اجرایی بدانید؛ Scripted Input، Alert Action و Custom Search Command با دسترسی پلتفرم اجرا می‌شوند.

اقدام مدیریتی و Search را با _audit و خطای پلتفرم را با _internal و دسترسی محدود پایش کنید. Retention ممیزی و نسخه بیرون پلتفرم سیاست مستقل می‌خواهد. 8089 را به مدیریت و Peer ضروری محدود کنید، Input بلااستفاده را حذف، Credential مربوط HEC و API را Rotate و انقضای Certificate را پیش از پنجره نگهداری بررسی کنید. مبهم‌سازی با splunk.secret جای Vault را نمی‌گیرد؛ خود این فایل و Backup رمزدار تنظیمات را محافظت کنید. خروجی btool دارای Secret را در Ticket عمومی نگذارید.

## Indexing و Search را مستقل توسعه دهید

در نمونه Single-site با سه Indexer Peer، مقدار RF=3 سه نسخه داده خام و SF=2 دو نسخه قابل جست‌وجو نگه می‌دارد؛ SF نباید از RF بیشتر باشد. ظرفیت خرابی یک Peer، بازسازی Copy و Ingest هم‌زمان را در نظر بگیرید. کلاستری که فقط با تمام Nodeها جا دارد، پس از خرابی نمی‌تواند طراحی خود را حفظ کند. Cluster Manager نقش مدیریت است و Replica چهارم داده محسوب نمی‌شود. Fault Domain مستقل و برنامه بازیابی Manager یا روش افزونگی پشتیبانی‌شده همچنان لازم است.

ابتدا Manager و Peerها را به‌صورت Host امن Enterprise بسازید. روی Manager در بخش [clustering] از server.conf مقدار mode=manager و replication_factor=3 و search_factor=2 بگذارید. روی هر Peer از mode=peer و manager_uri=https://cm01.example.net:8089 و Listener مشخص Replication استفاده کنید. یک pass4SymmKey قوی و یکتا برای همین Cluster را با Configuration Management محافظت‌شده به تمام اعضای لازم برسانید؛ Secret واقعی را در دستور آموزشی یا Git ننویسید. سپس Restart را طبق روش سازنده انجام دهید و پیش از فرستادن داده Production سلامت Cluster را بررسی کنید.

### Listener مربوط Replication روی Peer؛ TLS و تنظیم Cluster را پیش از استفاده کامل کنید

```ini
[replication_port-ssl://9887]
serverCert = /opt/splunk/etc/auth/enterprise/server.pem
requireClientCert = true
sslVersions = tls1.2
```

Listener مربوط Replication، CA را از [sslConfig]/sslRootCAPath می‌گیرد؛ sslRootCAPath را داخل Stanza خود Listener ننویسید. Certificate هر Peer باید نقش Server و Client آن را پشتیبانی کند؛ هویت Peerهای مجاز را با Name Constraint مستند و ACL شبکه محدود کنید. Certificate دارای فقط serverAuth را به‌عنوان Client Certificate به کار نبرید.

این Fragment فقط Listener رمزگذاری‌شده Replication را تنظیم می‌کند و پیکربندی کامل Cluster نیست. تنظیمات اعتبارسنجی Certificate در مسیر Replication را از server.conf همین انتشار کامل و محدودیت هویت Peer را آزمایش کنید. Index کلاستری را از Bundle مدیر در etc/manager-apps و با repFactor=auto برای Index مدیریت‌شده توزیع کنید؛ indexes.conf هر Peer را مستقل تغییر ندهید و App مستقل قبلی را بدون اصلاح کپی نکنید. Bundle را روی Manager اعتبارسنجی و اعمال، سپس RF و SF را کنترل کنید. Search Head را با روش مستند Association به Manager، از Cluster آگاه کنید؛ فهرست ثابت Peer جای هماهنگی Cluster را نمی‌گیرد.

```bash
sudo -u splunk /opt/splunk/bin/splunk validate cluster-bundle
sudo -u splunk /opt/splunk/bin/splunk apply cluster-bundle
sudo -u splunk /opt/splunk/bin/splunk show cluster-status --verbose
```

این فرمان‌ها روی Cluster Manager اجرا می‌شوند و ممکن است ورود Administrator مجاز را بخواهند. پیش از apply باید validate موفق باشد. شاهد مطلوب، Upبودن Peerهای مورد انتظار، برقراری RF و SF و قابل جست‌وجوبودن تمام داده است؛ خروجی واقعی را ثبت کنید و از Transcript آماده موفقیت استفاده نکنید. نام DNS قابل دسترس و Certificate متناظر برای Peerها منتشر کنید و مدیریت و Replication را به شبکه مجاز محدود نگه دارید.

Search Head Cluster حداقل سه عضو سازگار، Deployer، Certificate، Secret مشترک و Load Balancer کاربران می‌خواهد. هر عضو را با Management URI یکتا، URI مشترک Deployer، پورت Replication انتخابی و Secret محافظت‌شده Initialize کنید؛ سپس Captain را یک‌بار با فهرست کامل اعضا Bootstrap کنید. Appها از Deployer توزیع می‌شوند، نه Deployment Server. انتخاب Captain، Searchهای زمان‌بندی‌شده، KV Store و سناریوی از دست رفتن یک عضو را بررسی کنید. این کار پیاده‌سازی مستقلی است و با Clone یک VM مربوط Search Head انجام نمی‌شود.

برای Deployment Server، App بررسی‌شده را در etc/deployment-apps بگذارید، در serverclass.conf کلاس هدف بسازید و Pilot Clientها را در deploymentclient.conf به Endpoint با TLS روی 8089 متصل کنید. CA مدیریت را در server.conf کلاینت معتبر کنید. با یک Client Class شروع کنید و پیش از گسترش، Hash برنامه تحویل‌شده و مقادیر مؤثر btool را بررسی کنید. تنظیم Deployment Client را خارج از App قابل حذف ناخواسته نگه دارید و کلید خصوصی مشترک میان تمام Fleet پخش نکنید.

[مرجع server.conf شاخه 10.2؛ Clustering و Listener رمزگذاری‌شده](https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.2/configuration-file-reference/10.2.0-configuration-file-reference/server.conf)

[معماری و حداقل اعضای SHC؛ تطبیق با انتشار منتخب پیش از اجرا](https://help.splunk.com/en/splunk-enterprise/administer/distributed-search/10.4/deploy-search-head-clustering/system-requirements-and-other-deployment-considerations-for-search-head-clusters)

## Replica جای Backup قابل بازیابی را نمی‌گیرد

Indexer Cluster داده را کپی می‌کند؛ حذف ناخواسته و بعضی خطاهای عملیاتی هم می‌توانند تکثیر شوند. این قابلیت نقطه تاریخی مستقل برای بازیابی نگه نمی‌دارد. Source تنظیمات و App، Certificate و کلید با رمزگذاری مناسب، splunk.secret، Bundleهای توزیع و Backup پشتیبانی‌شده KV Store را نگه دارید. Warm و Cold Bucket با فرایند Backup سازگار قابل کپی‌اند. از Hot Bucket در حال نوشتن صرفاً Copy نگیرید و آن را Backup معتبر ننامید. روش Snapshot سازگار مستند یا توقف برنامه‌ریزی‌شده سرویس را به کار ببرید؛ Roll اجباری و مکرر Hot، Bucket کوچک می‌سازد و کارایی Search را پایین می‌آورد.

Backup را خارج از دامنه خرابی Cluster و در صورت نیاز Immutable نگه دارید. RPO را برای رخداد Indexشده، Configuration و Knowledge Object جدا تعریف کنید. در محیط بازیابی ایزوله، یک Index را Restore و تعداد رخداد، پوشش زمانی، مجوز و Search نمونه را تأیید کنید؛ KV Store نیز روش Restore متناظر خودش را دارد. Multisite Cluster تاب‌آوری سایت را بهتر می‌کند، اما RF و SF سایت، پهنای باند و Locality باید طراحی شود. این قابلیت نه Backup جغرافیایی خودکار است و نه مصونیت از Administrator آلوده.

[سازگاری Backup و رفتار Hot، Warm و Cold Bucket](https://help.splunk.com/en/splunk-enterprise/administer/manage-indexers-and-indexer-clusters/10.2/back-up-and-archive-your-indexes/back-up-indexed-data)

## برای 100 GB در روز، Storage و Search را هم حساب کنید

فرض کنید سازمان نمونه روزانه 100 GB ده‌دهی وارد می‌کند، ۳۰ روز داده قابل Search می‌خواهد و Pilot برای مجموع rawdata و فایل Index ضریب 0.60 نسبت به ورودی نشان داده است. یک نسخه مستقل به 100 × 30 × 0.60 = 1,800 GB نیاز دارد. برای ۳۰ درصد فضای آزاد، مقدار 1,800 ÷ 0.70 تقریباً 2,572 GB می‌شود؛ سیستم‌عامل، Index داخلی، Acceleration، Summary، رشد و Backup هنوز اضافه نشده‌اند. ضریب 0.60 فرض مثال است و باید با اندازه‌گیری جایگزین شود؛ نسبت فشرده‌سازی تضمینی نیست.

برای RF=3 و SF=2، مدل دقیق‌تر اجزای rawdata و ساختار قابل Search را جدا می‌کند. اگر اندازه‌گیری به ازای هر GB ورودی، 0.20 برای rawdata و 0.40 برای ساختار Search نشان دهد، فرمول 100 × 30 × (0.20 × 3 + 0.40 × 2) برابر 4,200 GB در مجموع Peerهاست. با ۳۰ درصد فضای آزاد حدود 6,000 GB می‌شود؛ ظرفیت بازسازی، Acceleration و Backup باز هم جدا هستند. نحوه واقعی Copy و نسخه Nonsearchable فرق می‌کند؛ مدل را با روش ظرفیت‌سنجی سازنده و Bucket واقعی تطبیق دهید. ضرب تمام دیسک مستقل در RF میان‌بر محافظه‌کارانه‌ای است، اما اثر SF را پنهان می‌کند.

میانگین 100 GB در روز فقط حدود 1.16 MB/s است؛ Burst پس از وصل‌شدن WAN و ده‌ها Search هم‌زمان می‌توانند بار اصلی CPU و دیسک باشند. Ingest در p95، اندازه Event، هزینه Parsing، Search هم‌زمان و Retention هر Index را اندازه بگیرید. در Ingest Pricing، مصرف بر اساس معیار قرارداد سنجیده می‌شود، نه اندازه فشرده دیسک. Workload Pricing برای Enterprise هم عرضه می‌شود؛ فرض SVC مربوط Cloud را به Quote نصب On-premises منتقل نکنید. ES، پشتیبانی و Solutionهای دیگر بررسی مجوز جدا دارند. برای محصول، منطقه و قرارداد واقعی، Quote و تفسیر مکتوب مجوز بگیرید؛ این متن قیمت عمومی به ازای GB فرض نکرده است.

[مدل‌های رسمی قیمت‌گذاری پلتفرم؛ Ingest و Workload](https://www.splunk.com/en_us/products/pricing/platform-pricing.html)

## عیب‌یابی را با شاهد از دو سمت پیش ببرید

فرمان‌های این بخش ابزار تشخیص‌اند و نتیجه توصیف‌شده معیار پذیرش است، نه خروجی اجرای ثبت‌شده. Host مشکل‌دار، بازه UTC و نام فایل مبدأ را در بررسی ثابت نگه دارید. btool --debug ممکن است مقدار حساس نشان دهد؛ قبل از اشتراک Redact کنید. فقط مؤلفه‌ای را Restart کنید که تنظیم مؤثرش تغییر کرده و Checkpoint ورودی را حفظ کنید. حذف fishbucket راه‌حل عمومی Missing Log نیست؛ می‌تواند داده قدیمی را دوباره وارد و مجوز را مصرف کند.

### ۱. Forwarder وصل نمی‌شود

```bash
getent hosts splunk01.example.net
sudo -u splunkfwd /opt/splunkforwarder/bin/splunk list forward-server
sudo -u splunkfwd /opt/splunkforwarder/bin/splunk btool outputs list --debug
openssl s_client -connect splunk01.example.net:9997 -servername splunk01.example.net -CAfile ca-chain.pem -cert client-leaf.pem -key client.key -verify_hostname splunk01.example.net -verify_return_error </dev/null
sudo tail -n 100 /opt/splunkforwarder/var/log/splunk/splunkd.log
```

نشانه، Endpoint غیرفعال یا نبود Event تازه است. DNS باید Receiver درست را بدهد و TLS باید Chain و Name را معتبر و Client را مجاز بداند. Timeout به Route، ACL یا Listener غایب اشاره می‌کند؛ Certificate Alert بیشتر مربوط Trust، نام، انقضا یا EKU کلاینت است. روی Receiver با ss -lntp و inputs.conf مؤثر بررسی کنید. همان ایراد مسیر یا Certificate را اصلاح، در صورت تغییر تنظیم UF را Restart و Marker پذیرش را در Index مقصد پیدا کنید.

### ۲. ارتباط برقرار است ولی لاگ فایل دیده نمی‌شود

```bash
sudo -u splunkfwd test -r /var/log/auth.log
sudo -u splunkfwd /opt/splunkforwarder/bin/splunk btool inputs list --debug
sudo -u splunk /opt/splunk/bin/splunk btool indexes list infra --debug
sudo tail -n 100 /opt/splunkforwarder/var/log/splunk/splunkd.log
```

انتظار می‌رود فایل خواندنی، Monitor فعال و infra موجود باشد و پیام Permission یا رد Index دیده نشود. Glob غلط، ACL پس از Rotation، Input غیرفعال، Index اشتباه و زمان Event علت‌های متفاوت‌اند. Input یا ACL را اصلاح کنید؛ پیش از نتیجه‌گیری درباره اتلاف، بازه Search را بزرگ‌تر و _indextime را بررسی کنید. یک Marker بی‌خطر و یکتا اضافه و host/source و زمان ورودش را کنترل کنید؛ صرفاً برای تولید Event بیشتر Checkpoint را Reset نکنید.

### ۳. تأخیر Indexing افزایش پیدا می‌کند

```spl
index=_internal source=*metrics.log group=queue earliest=-30m
| stats max(current_size) as max_queue max(max_size) as queue_limit by host name

index=infra earliest=-1h
| eval lag=_indextime-_time
| timechart span=5m perc95(lag) by host
```

نشانه، دیررسیدن رخداد تازه و نزدیک‌ماندن Queue به سقف است. وجود فیلد را در قالب Metrics خود بررسی، Indexing Performance در Monitoring Console را باز و روی Indexer از iostat -xz 1 استفاده کنید. Storage اشباع، Parsing پرهزینه، انسداد Downstream و اختلاف ساعت راه‌حل یکسان ندارند. Parsing زائد را کم، گلوگاه Storage را اصلاح یا ظرفیت اندازه‌گیری‌شده اضافه کنید؛ با تغییر Timestamp تأخیر را پنهان نکنید. کاهش Backlog و برگشت p95 رخداد تازه به هدف را هنگام ادامه Ingest تأیید کنید.

### ۴. هشدار مجوز

```spl
index=_internal source=*license_usage.log type=Usage earliest=-24h
| stats sum(b) as bytes by idx st
| eval GB=round(bytes/1000000000,2)
| sort - GB
```

در قرارداد Ingest انتظار می‌رود گزارش، Index و sourcetype مصرف‌کننده Byte را مشخص کند؛ قرارداد Workload داشبورد معیار خودش را می‌خواهد. Source تکراری، Debug پرحجم، Replay یا مجوز منقضی و License Manager غیرقابل دسترس می‌توانند هشدار بسازند. Settings > Licensing و قرارداد واقعی را بررسی، Duplicate یا ارتباط Manager را اصلاح یا ظرفیت لازم را تهیه کنید. حذف Bucket، Ingest اندازه‌گیری‌شده را پاک نمی‌کند. دوره گزارش بعدی و Alert روی معیار قرارداد را کنترل کنید.

### ۵. Search کند شده است

```spl
index=_internal sourcetype=scheduler earliest=-1h
| stats count by status savedsearch_name
| sort - count

| rest /services/search/jobs
| table sid runDuration dispatchState scanCount eventCount
```

انتظار می‌رود Search زمان‌بندی‌شده در پنجره خود تمام شود و Job تعاملی انباشته نشود. دیدن REST Job به Role وابسته است؛ این دستور تشخیص ادمین است، نه Dashboard عمومی. با Job Inspector هزینه Scan، تأخیر Peer و هزینه Command را جدا کنید. ابتدا Index و زمان را محدود، transaction یا join غیرضروری را با الگوی مناسب stats جایگزین، Scheduleها را پخش و بار Acceleration را بررسی کنید. همان Query و همان بازه را قبل و بعد بسنجید؛ Search Head بیشتر، دیسک کند Indexer را اصلاح نمی‌کند.

### ۶. فضای Indexer پر یا Mount ناپدید شده است

```bash
df -hT /srv/splunk
df -i /srv/splunk
findmnt /srv/splunk
iostat -xz 1 5
sudo -u splunk /opt/splunk/bin/splunk btool indexes list --debug
sudo tail -n 150 /opt/splunk/var/log/splunk/splunkd.log
```

نشانه می‌تواند توقف Indexing، هشدار فضای آزاد، خطای نوشتن یا تأخیر شدید باشد. Mount درست باید حاضر، برای splunk قابل نوشتن و دارای فضای آزاد طراحی‌شده باشد. Mount غایب ممکن است نوشتن را به دیسک OS ببرد؛ سقف حجمی Retention هم می‌تواند داده را قبل از عمر مطلوب حذف کند. Mount و Permission را اصلاح یا ظرفیت معتبر اضافه کنید؛ Retention فقط با تأیید مالک داده تغییر کند. برای بهترشدن df پوشه Bucket را دستی حذف نکنید. Searchپذیری Index و شروع دوباره Ingest بدون خطای Storage تازه را تأیید کنید.

### ۷. خطای Certificate پس از تمدید

```bash
openssl x509 -in leaf.pem -noout -dates -issuer -subject -ext subjectAltName
openssl verify -CAfile root-ca.pem -untrusted issuer-chain.pem leaf.pem
sudo -u splunkfwd /opt/splunkforwarder/bin/splunk btool server list sslConfig --debug
sudo -u splunkfwd /opt/splunkforwarder/bin/splunk btool outputs list --debug
```

انتظار، تاریخ معتبر، SAN درست، Chain کامل و Trust Bundle مورد نظر در تنظیم مؤثر است. تمدید ممکن است Issuing CA را عوض، Intermediate را حذف یا کلید ناخوانا ایجاد کند. Public Key مربوط Certificate و Private Key را محلی مقایسه کنید و ماده خصوصی را منتشر نکنید. Chain، مسیر، Permission یا Trust Bundle را اصلاح، سرویس مربوط را Restart و Probe دارای Certificate و آزمون تحویل Event را تکرار کنید. خاموش‌کردن Verification روش تمدید نیست.

### ۸. Cluster به RF یا SF نمی‌رسد

```bash
sudo -u splunk /opt/splunk/bin/splunk show cluster-status --verbose
sudo -u splunk /opt/splunk/bin/splunk show shcluster-status
sudo journalctl -u Splunkd.service --since '-30 min' --no-pager
```

cluster-status را روی Manager و shcluster-status را فقط روی عضو SHC اجرا کنید. وضعیت مطلوب، اعضای مورد انتظار Up، Factor برقرار، داده قابل Search و Captain سالم است. Peer غایب، ACL مربوط Replication، دیسک ناکافی، Secret ناسازگار، خطای Bundle و اختلاف ساعت شاهد متفاوت دارند. ارتباط، Certificate یا ظرفیت را اصلاح، توزیع Bundle را کنترل و روش مستند بازیابی Peer را دنبال کنید. RF و SF را صرفاً برای سبزشدن صفحه پایین نیاورید. بازیابی Factor، Search نمونه، Job زمان‌بندی‌شده و تحمل خرابی Fault Domain طراحی‌شده را تأیید کنید.

## پذیرش، ارتقا و Rollback

| کنترل | شاهد پیش از تحویل |
| --- | --- |
| امنیت | HTTPS و mTLS با بررسی نام، رد Client غیرمجاز، آزمون RBAC و Audit و ثبت مسئول کلید و انقضا. |
| کیفیت داده | یک رخداد شناخته‌شده از هر منبع با host، زمان، sourcetype و فیلد درست؛ Collector و Rotation پس از Restart سالم. |
| نگهداری | سقف Index با روز و حجم مصوب سازگار؛ حذف یا آرشیو Frozen صریح پذیرفته و قدیمی‌ترین زمان قابل Search اندازه‌گیری شده است. |
| بازیابی | Backup بیرونی در محیط ایزوله Restore، ‏RPO و RTO اندازه‌گیری، بازیابی Credential و KV Store لحاظ و Replica از Backup جدا شده است. |
| عملیات | Alert منبع غایب، Queue، Disk، Latency، Certificate، مجوز و Cluster به مسئول مشخص تحویل و روند ظرفیت بررسی شده است. |
| ارتقا | Release Note، Advisory، سازگاری UF و Add-on و ES، نیاز KV Store و ترتیب Rolling پشتیبانی‌شده در Staging بررسی شده است. |

پیش از ارتقا، Media معتبر، Configuration و نقطه بازیابی سازگار داده و KV Store را نگه دارید. ترتیب Manager، Peer، Search Head، Deployer و Forwarder را از راهنمای همان ارتقا بگیرید؛ Mixed Version فقط مرحله گذار پشتیبانی‌شده است، نه معماری دائمی. Rollback به معنای نصب Package قدیمی روی Data Directory مهاجرت‌کرده نیست. اگر Downgrade مستقیم پشتیبانی نمی‌شود، Backup متناظر قبل از ارتقا را روی Host سازگار Restore کنید و تکلیف رخدادهای بعد از نقطه بازیابی را مشخص کنید. این مسیر را قبل از تأیید پنجره نگهداری تمرین کنید.

## ادامه مسیر طراحی و مانیتورینگ

[Elastic Stack یا Splunk؛ معماری، مجوز و تصمیم سازمانی](/articles/elk-stack-vs-splunk-enterprise)

[راهنمای پیاده‌سازی Elastic Stack در سازمان](/articles/elk-stack-enterprise-installation-guide)

[گرافانا و زبیکس برای شاخص‌های زیرساخت در کنار لاگ](/articles/grafana-installation-zabbix-integration)

[تفکیک دسترس‌پذیری، Backup و Disaster Recovery](/articles/high-availability-backup-disaster-recovery-enterprise-guide)

## پرسش‌های عملیاتی

### آیا نصب Enterprise، قابلیت Enterprise Security می‌دهد؟

خیر. ES راهکار دارای مجوز جدا با نیازمندی سازگاری، Onboarding داده و عملیات مستقل است.

### آیا Cluster سه‌عضوی Backup هم محسوب می‌شود؟

خیر. Replica به دسترس‌پذیری کمک می‌کند؛ حفظ وضعیت تاریخی قابل بازیابی به Backup مستقل و Restore اثبات‌شده نیاز دارد.

### آیا Retention سی‌روزه، نگهداری ۳۰ روز را تضمین می‌کند؟

خیر. سقف حجم، زمان رخدادهای Bucket و ظرفیت Storage هم بر خروج داده اثر دارند. قدیمی‌ترین رخداد قابل Search و ظرفیت را پایش کنید.

## منابع سازنده و مرز اعتبارسنجی

برای تطبیق Configuration به مرجع نسخه‌دار لینک‌شده رجوع کنید. بخشی از راهنماهای قابل دسترس Windows و SHC در زمان بررسی مربوط به شاخه جدیدتر بودند؛ مبنای سیستم‌عامل، S2S، Index و نحو Clustering همان مرجع 10.2 و رسانه منتخب است. تطبیق با سند، شاهد اجرای واقعی نیست. آزمون پذیرش Pilot و تمرین Restore را پیش از Production روی Build دقیق مقصد انجام دهید.

[Security Advisoryهای رسمی Splunk](https://advisory.splunk.com/)

[Release Noteهای رسمی Ubuntu](https://documentation.ubuntu.com/release-notes/)

[نسخه Markdown فارسی](/downloads/splunk-enterprise-installation-guide/article.fa.md)

[نسخه Markdown انگلیسی](/downloads/splunk-enterprise-installation-guide/article.en.md)