OCI_Logging&Logging Analyticsにnginxのログを渡す
Categories:
nginxのログをOCI logging/Logging Analyticsに渡す
ocidとってfluent bitに設定する必要があったり、パーサーの定義にLoggingでのログが必要だったり、いろいろ設定入り組んでて最初は上から順番に綺麗にできないので平行に進めていく感じで。
Fluent Bitの構成
Ubuntu on ARM構成が管理エージェントに対応してないためFluent Bitを入れて送信する
インストール
リポジトリGPGキーの追加
curl https://packages.fluentbit.io/fluentbit.key | gpg --dearmor | sudo tee /usr/share/keyrings/fluentbit-keyring.gpg > /dev/null
APTソースリストへの登録
sudo touch /etc/apt/sources.list.d/fluent-bit.list echo "deb [signed-by=/usr/share/keyrings/fluentbit-keyring.gpg] https://packages.fluentbit.io/ubuntu/noble noble main" | sudo tee /etc/apt/sources.list.d/fluent-bit.list
※nobleはUbuntu 24のコードネームらしい。Ubuntuのバージョンに合わせて変える。
Fluent Bitインストール
sudo apt-get update sudo apt-get install fluent-bit sudo systemctl start fluent-bit sudo systemctl enable fluent-bit systemctl status fluent-bit #これやらないとエラーになった。ポディションDBがこの下に作成される。 sudo mkdir -p /var/lib/fluent-bit
Fulent Bit for OCI Ligging Services Pluginの構成(Logging Analitics Pluginは標準搭載されているがLogging へのPluginは標準で搭載されていので有志の作成物をつかう)
sudo apt install -y build-essential make gcc curl sudo apt install -y golang-go go version ubuntu@instance-blogs:~$ go env | grep -E 'GO(OS|ARCH)|CGO_ENABLED' GOARCH='arm64' GOOS='linux' CGO_ENABLED='1' ubuntu@instance-blogs:~$ git clone https://github.com/mattn/ocilogs-for-fluent-bit.git cd ocilogs-for-fluent-bit ubuntu@instance-blogs:~/ocilogs-for-fluent-bit$ make mkdir -p ./bin go build -buildmode c-shared -o ./bin/ocilogs.so ./ go: downloading github.com/fluent/fluent-bit-go v0.0.0-20220311094233-780004bf5562 go: downloading github.com/sirupsen/logrus v1.9.0 go: downloading github.com/ugorji/go/codec v1.1.7 go: downloading github.com/google/uuid v1.3.0 go: downloading github.com/oracle/oci-go-sdk v24.3.0+incompatible go: downloading golang.org/x/sys v0.0.0-20220715151400-c0bba94af5f8 ubuntu@instance-blogs:~/ocilogs-for-fluent-bit$ sudo mkdir /opt/fluent-bit/lib/ sudo cp bin/ocilogs.so /opt/fluent-bit/lib/
- Pluginを使えるようにする
sudo vi /etc/fluent-bit/plugins.conf ↓追記 [PLUGINS] Path /opt/fluent-bit/lib/ocilogs.so
OCIアクセス設定(ほんとはInstance PrincipalsにしたかったけどOCI Logging PluginがAPIキーにしか対応してなかったため)
APIのキーを発行してここに追加bash -c "$(curl -L https://raw.githubusercontent.com/oracle/oci-cli/master/scripts/install/install.sh)" oci setup config
はい、はいと先に進んでいけば、/home/ubuntu/.oci/config とkey fileを作ってれる。→OCIコンソールからAPIキーを発行して、ここで作られたPublic keyを張り付ける
※Loging SeviceのRegionがTokyoの場合はconfigのregionもap-tokyo-1に書き換えるsystemctl からconfigが見えるようにする(デフォルトだとfluent bit が動くユーザー(デフォルトroot)のhome配下の.ociディレクトリを見に行ってしまうため)
sudo mkdir -p /etc/systemd/system/fluent-bit.service.d sudo vi /etc/systemd/system/fluent-bit.service.d/oci.conf [Service] Environment=OCI_CONFIG_FILE=/home/ubuntu/.oci/config #設定再読み込み sudo systemctl daemon-reload ubuntu@instance-blogs:~$ systemctl show fluent-bit -p Environment Environment=OCI_CONFIG_FILE=/home/ubuntu/.oci/config ubuntu@instance-blogs:~$
Instance Principal用の設定(今回やってない)
sudo mkdir -p /etc/systemd/system/fluent-bit.service.d sudo vi /etc/systemd/system/fluent-bit.service.d/oci.conf [Service] Environment="OCI_CLI_AUTH=instance_principal" [DEFAULT] region = ap-tokyo-1 #設定再読み込み sudo systemctl daemon-reload
Parsers 設定 ※ChatGPTに作ってもらうのがいい。ここがマッチしないとLogging Servicesに構造化されずに送られてしまう。逆にパーサーが働いているかはLogging Servicesに送られたjSON形式のログを見ればわかる。
sudo vi /etc/fluent-bit/parsers.conf #Nginxのログフォーマットに合わせて追加 [PARSER] Name nginx_custom Format regex Regex ^(?<remote_addr>[^ ]+) (?<ident>[^ ]+) (?<user>[^ ]+) \[(?<time>[^\]]+)\] "(?<method>[A-Z]+) (?<uri>[^ ]+) (?<protocol>[^\"]+)" (?<status>[0-9]{3}) (?<bytes_sent>[0-9-]+) "(?<referer>[^\"]*)" "(?<agent>[^\"]*)" (?<request_time>[0-9.]+)$ Time_Key time Time_Format %d/%b/%Y:%H:%M:%S %z [PARSER] Name nginx_error Format regex Regex ^(?<time>\d{4}\/\d{2}\/\d{2} \d{2}:\d{2}:\d{2}) \[(?<level>[^\]]+)\] +(?<pid>\d+)#(?<tid>\d+): (?<message>.*)$ Time_Key time Time_Format %Y/%m/%d %H:%M:%S
転送設定
sudo vi /etc/fluent-bit/fluent-bit.conf #以下はsite1用、log_idはLogging Servicesに作った各ログのocid #デフォルトのcpuはコメントアウトする #Read_from_Head Onはファイルの最初から読み込むという設定。デフォルトだとfluent bit起動後に出力されたログしか転送しない #[INPUT] # name cpu # tag cpu.local # # # Read interval (sec) Default: 1 # interval_sec 1 [INPUT] Name tail Path /home/ubuntu/site1/logs/access.log Tag site1_nginx.access Refresh_Interval 5 DB /var/lib/fluent-bit/nginx-access_site1.db Skip_Long_Lines On Read_from_Head On Parser nginx_custom [INPUT] Name tail Path /home/ubuntu/site1/logs/error.log Tag site1_nginx.error Refresh_Interval 5 DB /var/lib/fluent-bit/nginx-error_site1.db Skip_Long_Lines On Read_from_Head On Parser nginx_error #[OUTPUT] # name stdout # match * [OUTPUT] Name ocilogs Match site1_nginx.access log_id ocid1.log.oc1.ap-tokyo-1.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx source site1_nginx.access subject access_log [OUTPUT] Name ocilogs Match site1_nginx.error log_id ocid1.log.oc1.ap-tokyo-1.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx source site1_nginx.error subject error_log
OCI Logging Service / OCI Logging Analytics構成
転送パターンは2パターンあるがパターン1を採用
- パターン1:Nginx(on OCI Compute) –>Fluent Bit(on OCI Compute) –> OCI Logging Service –> Connector Hub –> OCI Logging Analytics
- パターン2:Nginx(on OCI Compute) –>Fluent Bit(on OCI Compute) –> OCI Logging Service, Nginx(on OCI Compute) –>Fluent Bit(on OCI Compute) –> OCI Logging Analytics
※1,2はInstance Principalを使わない場合は不要
ダイナミックグループ作成(Compute Instance → Logging Serviceのアクセス許可のため)
Identity & Security > Domains > OracleIdentityCloudService(Reasion:Ashuburn,Compartment:root) > Dynamic groups > Create dynamic group- Name: Dynamic_Group_To_Use_Logging_Service_at_Tokyo
- Matching rules: ALL {instance.id = ‘ocid1.instance.oc1.ap-tokyo-1.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’}
- OCI ComputeのOCIDを指定する
ポリシー付与(Compute Instance → Logging Serviceのアクセス許可のため)
Identity & Security > Policies > Create Policy- Name: Policy_To_Use_Logging_Service_at_Tokyo
- Compartment: Blogs
- Statements: allow dynamic-group OracleIdentityCloudService/Dynamic_Group_To_Use_Logging_Service_at_Tokyo to use log-content in compartment Blogs
※Fluent Bit(on OCI Compute) –> OCI Logging Analytics を実施する場合は以下のポリシーも付与。でも今回は実施してない
allow dynamic-group LogSendInstances to use loganalytics-features-family in tenancy allow dynamic-group LogSendInstances to use loganalytics-log-groups in tenancy
Logging Services構成
- 東京リージョンでロググループを一つ作る(アクセス許可とかその辺のみっぽいのでNginxログは1つのロググループ運用にする)
Observability & Management > Log Groups >Create Log Group- Region: Tokyo
- Compartment: Blogs
- Name: Nginx-Logs
- 作ったロググループの中に各種ログを作っていく
Observability & Management > Logging > Log Groups > (Nginx-Logs) > Logs > Create custom logCompartment: Blogs
Name: site1_nginx_access_log
Select Log Retention: 30days
Compartment: Blogs
Name: site1_nginx_error_log
Select Log Retention: 30days ↓のログはConnector のログっぽくConnector 作成後にlog runみたいなボタンを押したら勝手にできた
Compartment: Blogs
Name: NginxLog_to_Analytics_runlog
Select Log Retention: 30days
- 東京リージョンでロググループを一つ作る(アクセス許可とかその辺のみっぽいのでNginxログは1つのロググループ運用にする)
Logging Analytics構成
リージョンごとのサービスっぽくて各リージョンで初めて使うときActivateする必要がある(Activateボタンがある)
有効化すると自動で以下のポリシーが割り当てられる- Name: logging_analytics_automatic_service_policies
- Compartment: root
- Statements:
- define tenancy sampledata as ocid1.tenancy.oc1..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
- endorse group Administrators to read loganalytics-features-family in tenancy sampledata
- endorse group Administrators to read loganalytics-resources-family in tenancy sampledata
- endorse group Administrators to read compartments in tenancy sampledata
- allow service loganalytics to READ loganalytics-features-family in tenancy
- allow service loganalytics to READ compartments in tenancy
Logging Analyticsもロググループは1つの運用
Observability & Management > Logging Analytics> Administration > Log Groups > Create Log Group- Region: Tokyo
- Compartment: Blogs
- Name: Nginx-LogAnalytics-Group
アクセスログ用とエラーログ用のパーサーを作る
Observability & Management > Logging Analytics> Administration > Parsers > Create ParserName: Nginx_Errorlog_Costom_Parser
Type: JSON
Loggingから取得したサンプルのログを張り付けると解析してフィールドを抜き出してくれるので必要なフィールドに(よくわからんので適当に)定義を入れていく(この列が解析に使えるのだと思われえる)
Name: Nginx_Accesslog_Costom_Parser
Loggingから飛んでくるソースを定義していく(Analytics上のログ定義みたいなもの)
※ここ要注意:このNameはLogging上のログの中に含まれてるType属性と同じ名前にしないマッチ出来ない。
Observability & Management > Logging Analytics> Administration > Sources > Create SourceName: site1_nginx.access
Source Type: File
Enity Types: Nginx
Parses: Nginx_Accesslog_Costom_Parser
Name: site1_nginx.error
Source Type: File
Enity Types: Nginx
Parses: Nginx_Errorlog_Costom_Parser
Connector Hub構成
Observability & Management > Logging > Connectors > Create Connector- Name: NginxLog_to_Analytics
- Compartment: Blogs
- Source: Logging
- Target: Logging Analytics
ポリシーが勝手にできる
- Name: ConnectorPolicy_loggingAnalytics_2025-05-23T18.22.05.502Z
- Compartment: Blogs
- Statements:
allow any-user to {LOG_ANALYTICS_LOG_GROUP_UPLOAD_LOGS} in compartment id ocid1.compartment.oc1..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx where all {request.principal.type=‘serviceconnector’, target.loganalytics-log-group.id=‘ocid1.loganalyticsloggroup.oc1.ap-tokyo-1.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’, request.principal.compartment.id=‘ocid1.compartment.oc1..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’}
Fulent Bit起動
起動コマンド
sudo systemctl start fluent-bit sudo systemctl status fluent-bit
デバッグ用のコマンド(↓いくつか)
OCI Logging Serviceにアクセスできるか
ubuntu@instance-blogs:~/ocilogs-for-fluent-bit/ocilogs$ oci logging log get --log-group-id ocid1.loggroup.oc1.ap-tokyo-1.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --log-id ocid1.log.oc1.ap-tokyo-1.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --query "data.\"lifecycle-state\"" --region ap-tokyo-1 "ACTIVE" ubuntu@instance-blogs:~/ocilogs-for-fluent-bit/ocilogs$
エラーを見る
journalctl -u fluent-bit.service -n 100 --no-pager
※/etc/fluent-bit/fluent-bit.conf で log_level debug にするとよい