2026'da Grafana'yı Self-Host Etme: Dashboard'lar, Alert'ler ve Kalıcı Durum

“Grafana çalıştırmanın” iki farklı anlamı vardır: Bir container'ın mevcut olması veya servisin gerçek görevini tamamlaması. Önemli olan yalnızca ikincisidir. Buradaki kanıt; salt okunur bir data source eklemek, bir paneli kaydetmek, bir alert rule'u değerlendirmek ve bir contact point üzerinden test notification'ı iletmektir.

Grafana'nın amacı budur: metrics, logs ve traces üzerinden dashboard'lar ve alert'ler sunmak. Deployment, bu davranışın arkasındaki bileşenleri korumalıdır; bir port, bir volume ve bir certificate girdidir, sonuç değildir.

Grafana'nın production yapısı

Grafana HTTP process'i 3000 portunu dinler; bu portu application network üzerinde tutun ve yalnızca platform route'unu publish edin. Grafana için network contract, erişilebilir data source'lar ve alert delivery gerekiyorsa SMTP'dir. Private endpoint'leri internal DNS üzerinde tutun, yalnızca gerekli outbound çağrılara izin verin ve Grafana'ya scope'u sınırlandırılmış bir service credential sağlayın.

Sınırı kısa bir contract olarak yazılı hâle getirin: Gereksinimin sahibi kim, hangi credential kullanılıyor, kabul edilebilir timeout ne kadar ve hata nasıl görünüyor? Ardından şu transaction'ı çalıştırın: salt okunur bir data source ekleyin, bir panel kaydedin, bir alert rule'u değerlendirin ve bir contact point üzerinden test notification'ı iletin. Çalışma sırasında Grafana'nın kendi depoladığı metrics yerine query fan-out'u, dashboard refresh interval'larını, alert evaluation'ı ve plugin memory kullanımını gözlemleyin; çünkü bu workload, boşta duran bir container'a kıyasla daha faydalı bir başlangıç boyutu ortaya koyar.

Grafana'yı hareketli parçaları gizlemeden başlatma

Grafana'yı, bootstrap tamamlanana kadar route private kalacak şekilde başlatın.

docker run -d \
  --name grafana \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v grafana-data:/var/lib/grafana \
  -e GF_SECURITY_ADMIN_PASSWORD=replace-with-a-long-random-value \
  grafana/grafana:latest

Process döngüye girerse image'ın beklediği user ile mount edilen her path'in sahibi olan user'ı karşılaştırın. Çalışır durumda kalıyorsa önce 3000 portunu local olarak test edin, ardından doğrudan workflow'a geçin: salt okunur bir data source ekleyin, bir panel kaydedin, bir alert rule'u değerlendirin ve bir contact point üzerinden test notification'ı iletin. Image'ı version-pin işlemini ancak bu uçtan uca kontrol başarılı olduktan sonra yapın ve tam configuration'ı service'in yanında kaydedin.

Grafana'ya tek bir canonical address verin

TLS issuance, Grafana route'unun yalnızca yarısıdır. GF_SERVER_ROOT_URL değerini public HTTPS URL olarak ayarlayın. Trafiği içeride 3000 portuna gönderin ve generated URL'lerin ve secure cookie'lerin tutarlı kalması için external scheme'i forward edin.

Grafana senaryosunun tamamını yalnızca root page'i açarak değil, temiz bir network üzerinden test edin. 502 veya certificate hatası automatic domain and TLS setup ile ayrıştırılabilir. Trafik process'e ulaşıyor ve dashboard'lar SQLite file'ıyla birlikte kayboluyor ya da OAuth callback'leri localhost kullanıyorsa, redirect'leri üst üste eklemek yerine bu koşulu ortaya çıktığı yerde teşhis edin.

Grafana restore planını launch öncesinde tasarlayın

Kalıcı recovery set'i Grafana database'ini, plugin'leri ve provision edilmiş configuration'ı içerir. Bootstrap öncesinde /var/lib/grafana mount edin, zararsız sample data yazın ve bu path'in gerçekten persistent olduğunu kanıtlamak için container'ı değiştirin. Bir volume, data'yı container replacement işleminden korur; ancak host kaybına, yanlışlıkla silinmeye veya application-level corruption'a karşı koruma sağlamaz.

Data source'u dikkate alan backup'lar alın: Gerektiğinde canlı database'ler için logical dump kullanın ve file'ları yalnızca tutarlı bir state'den kopyalayın. Şifrelenmiş bir kopyayı Grafana host'undan uzakta tutun. Restore için acceptance criterion nettir — user'lar, folder'lar, dashboard'lar, alert rule'lar ve data-source metadata geri gelmeli, test alert değerlendirilmelidir. restore-tested backup guide, yalnızca job success'in neden yeterli olmadığını açıklar.

Geçici setup erişimini kapatın

Güvenli bir Grafana deployment'ı authority'yi kaldırarak başlar. Admin/admin bilgilerini kullanmaya devam etmekten veya anonymous access'i yanlışlıkla açık bırakmaktan kaçının; bunun yerine bootstrap admin password'ünü değiştirin, data-source editing yetkisini kısıtlayın ve service-account token'larını scope'landırın.

Sample GF_SECURITY_ADMIN_PASSWORD değerini hemen değiştirin, image'ın dışında saklayın ve açığa çıkarsa bir administrator credential gibi rotate edin. Administrative route'ları kısıtlayın, dependency'ler için private DNS kullanın ve her bind mount'u gözden geçirin. Log'lar merkezi olarak gönderildiğinde, server'dan çıkmadan önce secret'ları ve private content'i filtreleyin.

Riskli Grafana değişikliğini prova edin

Çalışan bir container gereklidir ancak yeterli değildir. Service-level indicator, “salt okunur bir data source eklemek, bir paneli kaydetmek, bir alert rule'u değerlendirmek ve bir contact point üzerinden test notification'ı iletmek” işleminin başarıyla tamamlanmasıdır; olası pressure signal'ları ise Grafana'nın kendi depoladığı metrics yerine query fan-out, dashboard refresh interval'ları, alert evaluation ve plugin memory'dir.

Change control önemlidir; çünkü Grafana database migration'ları ve plugin compatibility, aynı provisioning file'larıyla staged upgrade gerektirir. Eski image'ı koruyun, migration'ları kopyalanmış state üzerinde test edin ve schema ilerledikten sonra rollback'in desteklenip desteklenmediğini belgeleyin. Dashboard'lar SQLite file'ıyla birlikte kayboluyor veya OAuth callback'leri localhost kullanıyorsa, çalışan environment'tan farklılık gösteren ilk boundary'yi teşhis edin.

Bilinen iyi durumdaki Grafana deployment'ını kaydedin

Grafana için launch öncesinde known-good transaction tanımlayın: salt okunur bir data source ekleyin, bir panel kaydedin, bir alert rule'u değerlendirin ve bir contact point üzerinden test notification'ı iletin. Gereksinimleri, beklenen response'u ve cleanup adımlarını secret değerleri olmadan version control'e koyun. Bu referansı oluşturmak için kullanılan image'ı pinleyin.

Bir replacement'ı ve bağımsız bir restore'u doğrulamak için transaction'ı kullanın. Restore edilen service yalnızca user'lar, folder'lar, dashboard'lar, alert rule'lar ve data-source metadata geri geldiğinde ve test alert değerlendirildiğinde kabul edilebilir. Aynı zamanda Grafana'nın kendi depoladığı metrics yerine query fan-out'u, dashboard refresh interval'larını, alert evaluation'ı ve plugin memory kullanımını gözlemleyin; en yavaş veya en kısıtlı bileşeni service-level alert'e dönüştürün.

Gate'in bir negative case'i de olmalıdır: Test identity'nin erişebildiği data source'lara ve alert delivery gerekiyorsa SMTP'ye erişimini geçici olarak engelleyin. Grafana'nın actionable bir error ürettiğini ve data'yı koruduğunu doğrulayın, geçerli koşulu geri yükleyin ve known-good transaction'ı tekrarlayın. Her iki sonucu saklamak, yüzeysel bir health endpoint'inin production'daki tek kanıt hâline gelmesini önler.

Dockup, Grafana için hangi işleri ortadan kaldırır?

Routing, certificate'lar, service replacement ve bağlı storage makul automation hedefleridir. Dockup bunları Grafana için yönetir; ayrıca ilgili managed database'i provision edebilir veya customer's own server'ındaki service'lere bağlanabilir.

Ancak Grafana'nın trust policy'sini kendi başına belirlememelidir. Deployment sonrasında GF_SERVER_ROOT_URL değerini public HTTPS URL olarak ayarlayın, bu boundary'yi uygulayın — bootstrap admin password'ünü değiştirin, data-source editing yetkisini kısıtlayın ve service-account token'larını scope'landırın — ve şu senaryonun sonucunu doğrulayın: salt okunur bir data source ekleyin, bir panel kaydedin, bir alert rule'u değerlendirin ve bir contact point üzerinden test notification'ı iletin. Sonuç, application-specific acceptance test içeren one-click infrastructure'dır.

Sık sorulan sorular

Production deployment için Grafana'nın neye ihtiyacı vardır?

Grafana container'ını 3000 portu üzerinden tek bir HTTPS origin'e route edin. Supporting network requirement, erişilebilir data source'lar ve alert delivery gerekiyorsa SMTP'dir. Salt okunur bir data source ekleyemeden, bir panel kaydedemeden, bir alert rule'u değerlendiremeden ve bir contact point üzerinden test notification'ı iletemeden Grafana'yı hazır kabul etmeyin.

Hangi Grafana data'sı backup'a dahil edilmelidir?

/var/lib/grafana'yı persist edin ve Grafana database'ini, plugin'leri ve provision edilmiş configuration'ı aynı recovery manifest'ine dahil edin. Temiz bir Grafana restore'u yalnızca user'lar, folder'lar, dashboard'lar, alert rule'lar ve data-source metadata geri geldiğinde ve test alert değerlendirildiğinde başarılı sayılır.

Reverse proxy arkasındaki Grafana HTTPS gerektirir mi?

Public Grafana origin için HTTPS kullanın ve 3000 portunu internal route üzerinde tutun. Grafana ayarını doğru uygulayın: GF_SERVER_ROOT_URL değerini public HTTPS URL olarak ayarlayın. Grafana için HTTPS, credentials veya user content'in transit hâlinde korunmasını ve origin'e duyarlı client davranışının tutarlı kalmasını sağlar.

Grafana upgrade'i nasıl test edilmelidir?

Mevcut Grafana state'ini izole bir deployment'a restore edin, candidate version'ı uygulayın ve acceptance transaction'ını tekrarlayın. Özellikle dikkatli olun; çünkü Grafana database migration'ları ve plugin compatibility, aynı provisioning file'larıyla staged upgrade gerektirir. Data migration ve rollback boundary'leri anlaşılana kadar önceki Grafana image'ını saklayın.