Cara Pasang Uptime Kuma dengan Docker

Apa yang anda bina

Satu bekas kecil yang memantau pelayan dan laman web anda dari luar dan memberitahu anda sebaik sahaja salah satu daripadanya berhenti memberi respons, melalui e-mel, Telegram, Discord atau webhook. Uptime Kuma ialah satu proses Node yang disokong oleh fail SQLite, jadi ia berjalan dengan lancar dalam 256-512 MB RAM, serta memberikan anda papan pemuka langsung, graf sejarah dan halaman status awam. Pemasangannya hanya memerlukan fail Compose sepuluh baris; bahagian yang sebenarnya penting ialah di mana anda menjalankannya dan sama ada makluman anda pernah dicetuskan dalam ujian, kerana monitor yang tidak pernah dibuktikan boleh menghubungi anda adalah lebih buruk daripada tiada langsung: ia membuatkan anda berasa dilindungi sedangkan ia tidak memantau apa-apa.

Jalankan monitor di lokasi yang tidak terjejas oleh gangguan

Keputusan ini menentukan kejayaan keseluruhan sistem, jadi ia perlu diutamakan. Jangan jalankan Uptime Kuma pada pelayan yang sama dengan servis yang dipantaunya. Jika monitor berada pada pelayan yang dipantau, peristiwa yang anda ingin kesan, seperti pelayan mati atau kehabisan memori, akan turut mematikan monitor tersebut. Akibatnya, anda tidak akan menerima sebarang amaran: ketiadaan isyarat daripada monitor yang mati kelihatan sama seperti "semuanya berjalan lancar." Terdapat perangkap yang lebih halus walaupun pelayan masih hidup: monitor yang dihalakan ke localhost berkongsi CPU dengan beban kerja. Lonjakan beban boleh menyebabkan pemeriksaan monitor tamat masa dan menukar status sasaran kepada down, yang merupakan penggera palsu, sedangkan pengguna sebenar masih mendapat perkhidmatan dengan baik.

Oleh itu, jalankan Uptime Kuma pada VPS yang berbeza daripada pelayan yang dipantau, sebaik-baiknya daripada penyedia atau wilayah yang berlainan. Capai perkhidmatan anda seperti cara pengguna anda mencapainya: melalui internet awam menggunakan hostname. Satu instans yang murah sudah memadai, dan satu VPS pemantauan yang kecil boleh memantau semua pelayan anda. Pemisahan ini sangat penting bagi aplikasi berat yang anda hoskan, kerana aplikasi seperti pustaka foto PhotoPrism atau Immich boleh menggunakan CPU secara maksimum selama berjam-jam semasa mengindeks import baharu. Monitor yang berkongsi perkakasan yang sama akan melaporkan servis sebagai mati sedangkan ia hanya sibuk. Untuk mengesan jika Uptime Kuma sendiri mati, tambahkan push heartbeat daripada cron di lokasi lain.

Prasyarat dan saiz pelayan

• VPS Ubuntu 24.04 baharu dengan Docker Engine dan pemalam Compose v2, dipasang daripada repositori apt rasmi Docker, bukan pakej docker.io distro yang biasanya ketinggalan.
• RAM 256 MB mampu menjalankan beberapa monitor; 512 MB hingga 1 GB adalah selesa untuk berpuluh-puluh monitor berserta reverse proxy, manakala penggunaan CPU hampir melahu di antara setiap semakan.
• Domain dan rekod DNS A (contohnya status.example.com yang menghala ke VPS), hanya jika anda mahukan TLS dan halaman status awam. Instans peribadi boleh melangkau DNS dan menggunakan VPN atau terowong SSH.
• Rangkaian keluar ke destinasi makluman: SMTP ke pembekal e-mel anda, atau HTTPS ke Telegram dan Discord.

Fail Compose

Letakkan ini di dalam /srv/uptime-kuma/compose.yaml.

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - kuma-data:/app/data

volumes:
  kuma-data:

Jalankan servis dan perhatikan but pertama:

sudo mkdir -p /srv/uptime-kuma
# save the file above as /srv/uptime-kuma/compose.yaml, then:
cd /srv/uptime-kuma && sudo docker compose up -d
sudo docker compose logs -f uptime-kuma

Permulaan yang betul akan mencatatkan Listening on 3001 dan kemudian menjadi senyap. Terdapat tiga perkara dalam fail tersebut yang diletakkan dengan sengaja.

127.0.0.1:3001:3001, bukan 3001:3001. Docker menerbitkan port dengan peraturan DNAT yang dinilai sebelum ufw melihat paket tersebut, jadi 3001:3001 secara terbuka akan meletakkan papan pemuka anda di internet awam tanpa mengira tetapan firewall anda. Melakukan binding pada loopback memastikan ia kekal peribadi, dengan hanya reverse proxy yang terdedah; instans peribadi boleh melangkau proxy dan mencapai 3001 melalui VPN WireGuard yang dihoskan sendiri.

Named volume pada /app/data. Segala maklumat yang diingati oleh Uptime Kuma, seperti pangkalan data SQLite, monitor, tetapan pemberitahuan dan logo halaman status, disimpan di situ. Jika ia hilang, anda akan bermula dengan skrin pentadbir yang kosong; ia adalah satu-satunya perkara yang wajib anda sandarkan.

Imej dipinkan kepada tag major, :2. Itu adalah barisan stabil semasa; semak Docker Hub untuk versi major terkini sebelum menyalinnya, dan jangan sesekali menjejaki tag yang berubah-ubah seperti latest, yang tidak digalakkan oleh pihak projek. Lompatan versi major pada imej ini merupakan migrasi pangkalan data sehala yang perlu anda lakukan secara sengaja, bukannya secara tidak sengaja semasa proses pull rutin.

Satu peringatan: /app/data mesti berada pada sistem fail dengan kunci fail POSIX. Docker volume tempatan adalah memadai; pada NFS, pangkalan data SQLite akan rosak dan anda akan mendapat SQLITE_BUSY serta database disk image is malformed, jadi jangan sesekali menggunakan network share.

Larian pertama: cipta akaun pentadbir

Layari instans tersebut melalui proksi anda di https://status.example.com, atau melalui terowong SSH: jalankan ssh -L 3001:127.0.0.1:3001 user@your-vps dan buka http://localhost:3001. Halaman pertama ialah borang tetapan untuk nama pengguna dan kata laluan pentadbir; tiada log masuk lalai. Pilih kata laluan yang sebenar: papan pemuka ini melihat alamat dalaman dan token bagi semua perkara yang anda pantau. Terlupa kata laluan kemudian hari? Tetapkan semula daripada hos, bukan pelayar:

sudo docker compose exec uptime-kuma npm run reset-password

Tambah saluran pemberitahuan anda dahulu, dan ujinya

Sediakan makluman sebelum menambah monitor, supaya anda boleh melampirkan saluran semasa anda mencipta setiap monitor. Pergi ke Settings kemudian Notifications kemudian Setup Notification, dan gunakan butang Test bagi setiap saluran untuk mengesahkan mesej sampai, kerana pemberitahuan yang tidak diuji adalah punca kedua paling kerap sesuatu persediaan gagal secara senyap.

Email (SMTP). Isikan host, port, penyulitan, nama pengguna, kata laluan, From dan To. Dua kombinasi yang berfungsi ialah 465 dengan "Secure" ditetapkan kepada TLS/SSL, atau 587 dengan STARTTLS. Bagi Gmail dan kebanyakan penyedia dengan pengesahan dua faktor, anda mesti menjana app password; kata laluan akaun biasa akan menghasilkan Error: Invalid login: 535-5.7.8 Username and Password not accepted.

Telegram. Mesej @BotFather, hantar /newbot, salin token bot. Untuk ID sembang anda, mesej bot baharu itu sekali, buka https://api.telegram.org/bot<token>/getUpdates, dan baca chat.id daripada JSON tersebut. Bot yang tidak pernah anda mesej terlebih dahulu mempunyai getUpdates yang kosong dan tiada tempat untuk dihantar.

Discord. Di dalam saluran, buka Edit Channel kemudian Integrations kemudian Webhooks kemudian New Webhook, salin URL, dan tampalkannya sebagai pemberitahuan Discord.

Generic webhook. Untuk perkara lain, webhook masuk Slack, endpoint tersuai, atau hook automasi rumah, jenis Webhook akan membuat POST payload JSON ke URL yang anda bekalkan, dan integrasi Apprise yang disertakan merangkumi kebanyakan daripada sembilan puluh lebih perkhidmatan lain dalam senarai tersebut. Jika anda lebih suka tiada pihak ketiga berada di antara gangguan servis dan telefon anda, pilih jenis ntfy terbina dalam dan halakannya ke pelayan ntfy yang anda kendalikan sendiri, yang menolak (push) mesej ke telefon bimbit anda melalui saluran yang anda kawal dari hujung ke hujung.

Tambah monitor, satu jenis pada satu masa

Klik Add New Monitor, pilih satu jenis, dan tetapkan Friendly Name, Check Interval (60 saat adalah nilai yang wajar), Retries (kegagalan berturut-turut sebelum status "down"; 2 atau 3 supaya satu paket yang tercicir tidak mencetuskan amaran), dan pemberitahuan yang perlu dihantar. Jenis yang akan anda gunakan:

• HTTP(s). URL penuh. Status "up" bermaksud kod status yang diterima (200-299 secara lalai; luaskan julat ini di bawah Accepted Status Codes jika 301 atau 401 adalah perkara biasa bagi anda). Ini adalah pilihan utama untuk laman web dan API.
• HTTP(s) - Keyword. Permintaan yang sama, tetapi status "up" juga memerlukan rentetan teks yang hadir, atau tiada jika Invert dipilih, dalam badan respons. Ini mengesan situasi di mana laman web memulangkan 200 OK semasa memaparkan "Error establishing a database connection", yang mana semakan HTTP biasa akan menganggapnya sebagai sihat. Ini juga merupakan semakan yang tepat untuk bahagian hadapan pelayar yang berhubung dengan backend berasingan, seperti skin kedai video Halcyon di atas Jellyfin, yang mana shell halamannya memulangkan 200 dengan jayanya walaupun pelayan media di belakangnya tidak dapat dicapai.
• TCP Port. Sambungan TCP kosong ke hos dan port, untuk perkara yang bukan HTTP: SSH pada 22, Postgres pada 5432, pelayan SMTP pada 25, atau pelayan permainan.
• Ping. ICMP echo: semakan kebolehcapaian dan kependaman yang ringan. Walau bagaimanapun, banyak rangkaian dan firewall awan menggugurkan ICMP, jadi monitor ping berwarna merah boleh bermaksud "hos tidak aktif" atau "pembekal menyekat ping"; sahkan dengan monitor TCP.
• DNS. Menyelesaikan rekod (A, AAAA, MX, TXT dan sebagainya) terhadap resolver yang anda namakan, dan boleh mengesahkan jawapan tersebut, bagi mengesan gangguan pendaftar atau DNS dengan lebih awal.
• Push. Monitor dari dalam ke luar, yang akan dibincangkan seterusnya.

Memantau cron job dengan monitor jenis push (heartbeat)

Setiap monitor di atas mencapai perkhidmatan anda dari luar. Monitor jenis push berfungsi secara terbalik: Uptime Kuma menunggu, dan tugasan anda memanggilnya untuk menyatakan "Saya telah berjalan." Ini adalah cara paling tepat untuk memantau sandaran atau cron: semakan HTTP hanya mengetahui sama ada URL memberi respons, tetapi hanya tugasan itu sendiri yang tahu sama ada ia telah selesai.

Cipta monitor jenis Push. Uptime Kuma akan menjana URL unik seperti:

https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=OK&ping=

Tetapkan Heartbeat Interval mengikut kekerapan tugasan dijalankan, ditambah dengan sedikit masa tambahan. Kemudian, tambahkan satu baris pada penghujung skrip anda supaya ia hanya dipanggil jika tugasan berjaya:

#!/usr/bin/env bash
set -euo pipefail
# ... your backup or job runs here; set -e aborts on any failure ...
curl -fsS --retry 3 "https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=backup+ok&ping="

Jika tugasan gagal, set -e akan terhenti sebelum arahan curl dijalankan; jika pelayan tidak berfungsi, skrip tersebut juga tidak akan berjalan. Dalam kedua-dua keadaan, heartbeat akan terhenti, dan sebaik sahaja tempoh interval-plus-retries tamat, Uptime Kuma akan menukar status monitor kepada down dan menghantar makluman kepada anda. Anggap token push tersebut sebagai rahsia: sesiapa yang memilikinya boleh memalsukan status sihat.

Membina halaman status awam

Halaman status ialah paparan yang menghadap pelanggan: perkhidmatan mana yang aktif dan sejarah terkini perkhidmatan tersebut, tanpa mendedahkan papan pemuka anda. Pergi ke Status Pages kemudian New Status Page, berikan nama dan slug (laluan awam, seperti /status/main), seret monitor yang anda mahukan ke dalam kumpulan seperti "Websites" dan "APIs", tambah logo dan penerangan ringkas, kemudian Save. Anda juga boleh mengikat halaman tersebut kepada domainnya sendiri supaya status.example.com menghidangkannya secara terus.

Dua peringatan: hanya tambah monitor yang anda sanggup dedahkan kepada umum, kerana halaman status mendedahkan kewujudan sesuatu perkhidmatan dan sama ada ia aktif; dan papan pemuka kekal di sebalik log masuk anda manakala halaman status sengaja dibuat awam dan tidak memerlukan pengesahan.

Letakkan di sebalik reverse proxy dengan TLS, dan perhatikan websocket

Untuk instans awam, letakkan reverse proxy di hadapan kontena yang terikat pada loopback bagi tujuan TLS dan nama hos. Perincian yang sering menyebabkan masalah: UI Uptime Kuma ialah aplikasi Socket.IO secara langsung, jadi proksi mesti menaik taraf sambungan WebSocket. Jika terlepas pandang, halaman akan dimuatkan tetapi tidak pernah bersambung; papan pemuka akan kekal pada status "Connecting...", degupan jantung (heartbeats) langsung tidak akan dikemas kini, dan konsol pelayar akan memaparkan WebSocket connection to 'wss://.../socket.io/...' failed.

Pasang nginx dan certbot, kemudian tulis vhost yang memproksi ke port loopback. Letakkannya pada port 80 buat masa ini dan biarkan certbot menambah TLS kemudian; cabaran, pemasa pembaharuan dan mod kegagalannya diliputi dalam mengeluarkan sijil Let's Encrypt dengan certbot dan nginx.

sudo apt install -y nginx certbot python3-certbot-nginx

Simpan ini sebagai /etc/nginx/sites-available/status.example.com; dua baris WebSocket adalah bahagian yang penting:

server {
    listen 80;
    server_name status.example.com;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
    }
}

Aktifkan tapak tersebut, uji konfigurasi, kemudian biarkan certbot menulis semula blok tersebut untuk mendengar pada 443, masukkan sijil dan tambah pengalihan HTTP-ke-HTTPS:

sudo ln -s /etc/nginx/sites-available/status.example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d status.example.com

Pasangan Upgrade dan Connection "upgrade" adalah kunci utama, dan proxy_read_timeout 3600s menghalang nginx daripada memutuskan soket yang beroperasi dalam jangka masa panjang; certbot menyalin kedua-duanya ke dalam blok 443 yang dijana. Jika anda sudah menjalankan beberapa kontena di sebalik satu proksi, menghalakan trafik melalui Traefik dengan TLS automatik melakukan perkara yang sama dengan label kontena dan memajukan naik taraf WebSocket secara lalai.

Jangan gunakan basic-auth pada keseluruhan vhost, kerana ia juga akan menyekat halaman status awam dan endpoint /api/push. Kekalkan log masuk terbina dalam Uptime Kuma, tambah fail2ban untuk memantau percubaan log masuk yang gagal berulang kali jika ia menghadap internet, dan jika papan pemuka tidak perlu menjadi awam, buang proksi dan aksesnya melalui VPN.

Pemantauan tamat tempoh sijil, dilakukan dengan betul

Pemantau HTTP(s) juga boleh memberi amaran kepada anda sebelum sijil TLS tamat tempoh: tandakan Certificate Expiry Notification dan Uptime Kuma akan menghantar makluman pada bilangan hari yang ditetapkan. Dua kesilapan menyebabkan ia tersalah baca. Pantau mengikut hostname, bukan IP, kerana permintaan tanpa SNI akan menerima sijil lalai pelayan dan anda akan melihat Hostname/IP does not match certificate's altnames. Selain itu, jangan tandakan Ignore TLS/SSL Error pada pemantau yang anda mahukan amaran tamat tempoh: togol tersebut adalah untuk hos dalaman yang menggunakan sijil self-signed (unable to verify the first certificate, DEPTH_ZERO_SELF_SIGNED_CERT), tetapi ia akan menghentikan Uptime Kuma daripada memeriksa sijil tersebut sama sekali, termasuk tarikh tamat tempohnya.

Sandaran: ia adalah satu direktori

Oleh kerana segala-galanya berada di dalam /app/data, sandaran merupakan salinan volum tersebut yang diambil semasa kontena dihentikan, supaya fail SQLite adalah konsisten:

cd /srv/uptime-kuma
sudo docker compose stop
sudo docker run --rm \
  -v uptime-kuma_kuma-data:/data \
  -v /var/backups/kuma:/backup \
  alpine tar czf /backup/kuma-$(date -u +%Y%m%dT%H%M%SZ).tgz -C /data .
sudo docker compose start

Sahkan nama sebenar volum tersebut dengan docker volume ls | grep kuma terlebih dahulu, memandangkan Compose meletakkan awalan nama direktori projek padanya. Kemudian, salin fail tarball keluar daripada pelayan tersebut, kerana sandaran yang disimpan pada VPS yang sama hanyalah satu salinan, bukan sandaran sebenar. Pemulihan dilakukan dengan cara sebaliknya: hentikan stack, ekstrak fail ke dalam volum /app/data yang kosong, kemudian mulakan semula.

Naik taraf

Naik taraf adalah proses penarikan imej (image pull):

cd /srv/uptime-kuma
sudo docker compose pull
sudo docker compose up -d

Kontena baharu akan menjalankan sebarang migrasi pangkalan data pada permulaan pertama; pantau docker compose logs -f. Lakukan sandaran seperti di atas sebelum menarik imej, dan kekal dalam tag major yang sama: beralih daripada :1 kepada :2 merupakan migrasi sehala, jadi lakukan sandaran terlebih dahulu dan semak nota keluaran (release notes).

Mod kegagalan, berserta rentetan yang akan anda lihat

"Down" palsu pada monitor yang menghala ke localhost. Monitor bertukar merah dengan timeout of 48000ms exceeded atau connect ETIMEDOUT, namun servis tersebut memberi respons daripada komputer riba anda. Jika ia menyasarkan hos yang sama tempat Uptime Kuma dijalankan, lonjakan CPU atau memori telah menyebabkan semakan tersebut kebuluran sumber, bukan sasaran itu sendiri. Alihkan monitor ke VPS berasingan dan sasarkan hostname awam.

connect ECONNREFUSED 127.0.0.1:443 (atau mana-mana port). Tiada apa-apa yang mendengar pada port tersebut: sama ada servis tidak berjalan, atau anda memantau localhost dari dalam kontena, di mana 127.0.0.1 ialah kontena itu sendiri, bukan pelayan anda. Pantau hostname awam, bukan loopback.

Invalid login: 535-5.7.8 Username and Password not accepted pada ujian e-mel. Kredensial SMTP salah, atau penyedia memerlukan kata laluan khusus aplikasi dan menerima kata laluan akaun anda. Jana kata laluan aplikasi dan tampal kata laluan tersebut.

connect ETIMEDOUT atau queryA ETIMEDOUT <host> pada ujian e-mel. Port salah, atau penyedia menyekat SMTP keluar. Sahkan 465 atau 587 sepadan dengan tetapan Secure/STARTTLS, dan uji dari hos menggunakan nc -vz smtp.example.com 587. Banyak penyedia menyekat port keluar 25 dan sesetengahnya menyekat port penghantaran sehingga anda memohon untuk membukanya.

self signed certificate atau unable to verify the first certificate pada ujian e-mel. Pelayan SMTP anda membentangkan sijil yang tidak dipercayai oleh Node; baiki sijil pelayan mel tersebut daripada menutup kelemahan itu.

Papan pemuka tersangkut pada "Connecting...", konsol menunjukkan WebSocket connection ... failed. Reverse proxy tidak menaik taraf WebSocket. Tambahkan header Upgrade dan Connection "upgrade" pada nginx, atau gunakan proksi yang memajukan header tersebut secara lalai seperti Traefik atau Caddy. HTML dimuatkan kerana itu adalah HTTP GET biasa; hanya soket langsung yang memerlukan naik taraf tersebut.

Monitor tamat tempoh sijil tidak memberi amaran, atau memberi amaran yang salah. Sama ada Ignore TLS/SSL Error ditanda, yang melumpuhkan semakan sijil, atau monitor menyasarkan IP dan membaca sijil yang salah akibat ketiadaan SNI, yang menunjukkan Hostname/IP does not match certificate's altnames. Nyah-tanda pilihan abaikan, dan pantau mengikut hostname.

SQLITE_BUSY atau database disk image is malformed dalam log. Volum /app/data berada pada sistem fail tanpa penguncian fail yang betul, biasanya NFS; alihkan ia ke volum Docker tempatan dan pulihkan daripada sandaran.

FAQ

Di manakah saya harus menjalankan monitor uptime saya?

Pada pelayan yang berbeza daripada pelayan yang dipantau, sebaik-baiknya daripada penyedia atau wilayah lain, dengan mencapai pelayan tersebut melalui hostname merentasi internet awam seperti yang dilakukan oleh pengguna anda. Jika monitor berkongsi kotak yang sama dengan sasarannya, gangguan yang mematikan pelayan tersebut akan turut mematikan monitor, dan hos yang terlebih beban akan menyebabkan monitor melaporkan "down" bagi servis yang sebenarnya berfungsi dengan baik. VPS kecil yang berasingan dapat mengelakkan kedua-dua masalah ini.

Bagaimanakah cara untuk mendapatkan makluman melalui Telegram atau e-mel?

Tambah saluran di bawah Settings kemudian Notifications, kemudian lampirkannya pada setiap monitor. Untuk Telegram, cipta bot dengan @BotFather dan baca chat.id daripada https://api.telegram.org/bot<token>/getUpdates; untuk e-mel, gunakan 465 untuk SSL atau 587 untuk STARTTLS dengan kata laluan aplikasi jika penyedia anda menggunakan pengesahan dua faktor. Tekan Test dan pastikan mesej sampai sebelum bergantung kepadanya.

Bolehkah Uptime Kuma memantau cron job atau skrip sandaran?

Ya, itu adalah monitor Push: Uptime Kuma memberikan anda URL dan anda curl URL tersebut pada penghujung skrip supaya ia hanya dicetuskan apabila berjaya. Jika tugasan gagal atau kotak tersebut down, heartbeat tidak akan sampai, dan anda akan dimaklumkan selepas tempoh selang masa berlalu. Ini adalah satu-satunya cara yang boleh dipercayai untuk mengetahui sama ada tugasan berjadual benar-benar berjalan, kerana pemeriksaan luaran tidak dapat melihat ke dalam skrip tersebut.

Uptime Kuma berbanding Zabbix, yang mana satu harus saya jalankan?

Uptime Kuma menjawab soalan "adakah ia aktif, dari luar, dan adakah ia memaklumkan saya" dalam masa sepuluh minit dengan hampir tiada penggunaan sumber, serta disertakan halaman status. Ia tidak mengumpul metrik mendalam seperti trend CPU, memori dan cakera atau ambang seluruh armada; untuk itu, pelayan pemantauan Zabbix yang lengkap adalah alat berasaskan ejen yang lebih berat, dan ramai orang menjalankan kedua-duanya. Masih belum membuat keputusan tentang apa yang perlu dijalankan? ringkasan kami tentang apa yang perlu di-self-host pada tahun 2026 meletakkan pemantauan dalam konteks yang lebih luas.