前回、Google Functions: console.infoやconsole.errorなどとログビューアの「重大度」の関係性という記事を投稿しました。そこではconsole.errorやconsole.infoなどのConsole APIでは、GCP上のログの重要度(severity)は、DEFAULTかERRORの二択になるということを説明しました。 GCP上の重要度はこの2つしか無いわけではなく、以下の9つのレベルがあります。 この投稿では、Google Cloudのロギングクライアントライブラリを使って、Cloud Functionsでも重要度を指定したロギングをする方法を説明します。 この投稿で学ぶこと Google Cloud Function & Node.jsで@google-cloud/loggingを使って重要度をつけたログを記録する方法 そして、その面倒くささ。
最近、ECS環境を構築する機会に恵まれました。当初はDockerのログドライバにawslogsを 指定してログをCloudWatch Logsに配信したのですが、このやり方には問題がありました。 ログストリームに複数行のログが１行ずつ蓄積されていくことです。 例えば、Railsの開発をしているとき下記のログを確認しながら開発を進めていくと思いますが、これらが1行ずつログストリームに配信されてしまいます。これでは不具合が発生した際、詳細を把握するのが困難になります。 Started GET "/" for 172.21.0.1 at 2021-12-31 12:30:46 +0000 Cannot render console from 172.21.0.1! Allowed networks: 127.0.0.0/127.255.255.255, ::1 Processing by Wel
Go ロギングライブラリ - Qiita
[2023/8/21 追記] 2023年8月にリリースされた Go1.21 から公式の準標準ライブラリに slog というライブラリが追加されました。 これが構造化ログに対応しているため、サードパーティライブラリを使わずとも json フォーマットでログを出力することが可能になりました。これから新規にプロジェクトを作る場合はまず slog から始めるのが良いと思います。 [参考] https://go.dev/blog/slog https://zenn.dev/88888888_kota/articles/7e97ff874083cf https://future-architect.github.io/articles/20230731a/ 標準ライブラリ https://golang.org/pkg/log/ 一番サクッとやるならこれ print 関数で palin text 出力な
KubeFest Tokyo 2020 は Kubernetes を利用している人、これから導入したい人が学ぶためのオンラインイベントです。富士通（株）のソフトウェアエンジニアである長谷氏・小林氏が、トラブル時の原因特定のために開発中のロギング強化機能について、後半は課題と解決策を話しました。 Request IDフラグ 長谷仁氏（以下、長谷）：ここから機能の紹介の中身になります。まずRequest IDフラグという、Request ID付与の有効／無効を制御する機能です。これをなぜ入れるのかというと、既存のログフォーマットを変えたくないユーザー向けとして、デフォルトではRequest IDの付与は今のところ無効にする予定で考えています。 次に有効／無効に関する制御の方式なんですけど、今は2つの方式が上がっていまして、どちらにするかは今コミュニティで議論中という状態です。1個目の方式がKu
この記事は Go4 Advent Calendar 2019 7日目の記事です。 2016年にGoのAdvent Calendarを書いた時はGo3までだったのに、今年はGo7まであり、Go言語の盛り上がりを感じます。 以前書いたGo言語のエラーハンドリングの記事がじわじわと反響をいただいており、とても嬉しく思います。 上の記事を書いた当時は趣味でGo言語を嗜んでいた程度ですが、ここ1年は仕事でGoの開発に関わり、エラーハンドリングとロギングの重要性を思い知らされた次第です。自分では適切なエラーハンドリングやロギングをしたつもりでも、いざリリースしてみるとログが不足していて調査に手間取ったり、逆に過剰で精査に時間がかかったり… 本記事はここ1年Goで書いたプログラムを運用してみて得た知見を記事に起こしたものです。 TL;DR エラーはWrapしつつ適切なメッセージを付与して返すといいよ！
kintoneを丸裸にするモニタリング＆ロギングツール / 20191108 kintone monitoring and logging
2019/11/08 6社の開発現場ツール大公開Night
本稿では、Google Could Platform(GCP)のGoogle Cloud Functions(GCF)で、Node.jsのロギングライブラリwinstonを使ったログの記録方法を説明します。 この投稿で学べること winstonをGoogle Cloud Functionsの関数に組み込む方法 winstonのメソッドの呼び出し方 winstonでオブジェクトの値をロギングする方法 winstonで記録したログの読み方 この投稿では説明しないこと winstonを使ってStackDriverにロギングする方法 winstonを使ってStackDriverに「重要度」をつけながらロギングする方法 winstonとStackDriverを組み合わせると、より自由度が高く分析しやすい構造でロギングすることが可能なりますが、この投稿ではそれについては説明しません。winstonを単
概要 zapを使っていて 書き込み先をio.Writerで自由に設定したい テストで時刻を固定値にしたい ログレベルによって標準出力、標準エラー出力を分けたい GCP Cloud Loggingのフォーマットでログ出力したい 全ログに付けたいフィールドがある 独自logパッケージでラップしたらcallerがおかしい とちょっとカスタマイズしたいケースのTipsです。 環境 Go 1.17 go.uber.org/zap v1.19.1 Tips 書き込み先をio.Writerで自由に設定したい zapのデフォルトの出力先は標準エラー出力ですが、期待通りのフォーマットでログが出力されているか確認したい時にio.Writerを渡してそこに書き込んでほしい場合です。 そんなときはzapcore.AddSyncを使います。 func NewWithWriter(w io.Writer) *zap.
Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
Google Functions & Node.js: console.logを使った最低限のロギング - Qiita
この投稿では、Google Cloud Platform(GCP)のGoogle Cloud Functions(GCF)のNode.js環境で、console.logを使った最低限のロギング手法について解説します。 この投稿で学ぶこと Google Cloud Functions & Node.jsでは、console.logで最低限のロギングは可能。 2行以上に渡るログは行ごとに分解されるので注意。 jsonPayloadを意識すると、オブジェクトの構造をログに出すことも可能。 GCFではconsole.logでログを残せて、「ログビューア」で確認できる まず、Google Cloud Functionsでどのようにロギングし、そのログをどうやって確認するのかを学びます。シンプルに1行のメッセージをconsole.logで記録してみましょう。
優れたロギング
この記事は、著者の許可を得て配信しています。 Good Logging プログラムがすべきことをきちんとこなしているかどうかを確認するには、与えられた入力からの出力を調べることができます。しかし、システムが大きくなると、何が起こっているかを理解するためのログも必要になります。優れたログメッセージは、問題のトラブルシューティングには欠かせません。しかし開発者の多くは適切な場所に十分な情報を記録していないのです。 問題のトラブルシューティングをするときには、ログを見ます。時にはバグが原因で間違った動作をしていることもあります。また、何も問題がない場合もあります。システムは正しく動作していますが、私たちはシステムが何をすべきかについて間違った予想をしていた場合です。どちらの場合も、ログはシステムで何が起こっているかを理解するのに役立ちます。また、新しい機能を完成させた後、探索的テストを行う際にも
# 以下の記事が書かれた時の版数は .NET Core 3.1 (3.1.201), ASP.NET Core 3.1 (3.1.3), Microsoft.Extensions.Logging.AzureAppServices 3.1.3 となります. 最低限エラーが残っていないと困るので……. Azure Portal にログインして、該当の Azure App Service にアクセス. 左メニューの 監視 / App Service ログ から「アプリケーション ログ (Blob)」を設定. nuget で Microsoft.Extensions.Logging.AzureAppServices をインストール. あとは Program.cs に AddAzureWebAppDiagnostics を追加すれば、Startup.cs の UseExceptionHandler
Rustのロギングについて解説とデモ
こんにちは、エンジニアの松本です。この記事はShinjuku.rs #14 において『Rustでロギングってどうすればいいんですか？』というタイトルでデモを中心に発表した内容をブログ記事としてまとめ直したものです。 Rustの標準的なロギングの仕組みとそれを実現するクレート群の使い方を解説します。 ※クレート：他のプログラミング言語でいうところの「ライブラリ」に相当する概念。ある機能を提供する再利用可能なコード群のこと。 ロギングは大切 アプリケーションを運用していくにあたって、様々な場面でアプリケーションの動作を確認したくなることがあります。処理はいつ終了したか、どの処理に時間がかかっているか、異常終了した原因は何でどこまでは正しく実行できたかを調べたいといった場面があります。 こういった場面で適切な場所に適切なログが記録されていれば、ソースコードを読んだり再現実験をしたりする前に状況を
ECS Exec を有効にする方法は各所で書かれてるので、この記事では軽く触れる程度にして、実運用に際して気になるロギングに関する情報が薄かったので調査・整理してみました。 例示しているのはFargateですが、内容自体はEC2onECSでも共通かと思います。 ECS Execは簡単便利、だけど、、 従来、Fargateのタスクにログインするには、以下のような手順を採る必要がありました。 ssmエージェントをコンテナにインストール ssmでアクティベーションコードを作成する タスク起動時に、アクティベーションコードと紐付けてSSMに登録 CLIから aws ssm start-session でログイン、またはマネコンから アクティベーションコードは有効期限がある(デフォルト1日)ため、基本的には必要になった都度発行する必要がありました。 これが ECS Exec だと以下のステップだけで
Pythonのロギングを覚えた - Qiita
いつも忘れてしまうので・・・ 簡単なスクリプトを書くときでも、きちんとloggingしておくとあとあと便利だと思うのですが、いつもやり方を忘れてしまいます。 なので、Loggingクックブックを参考に、ロガー作成の要素を整理してみました。また、毎回ファイルの冒頭に同じことを書くのもアレなので、setup_loggerという関数にしました def setup_logger(name, logfile='LOGFILENAME.txt'): logger = logging.getLogger(name) logger.setLevel(logging.DEBUG) # create file handler which logs even DEBUG messages fh = logging.FileHandler(logfile) fh.setLevel(logging.DEBUG) f
insightwatchのセキュリティチェックでオールグリーンを目指す（その2: CISベンチマーク ロギング編） | DevelopersIO
オペレーション部 江口です。 「insightwatchのセキュリティチェックでオールグリーンを目指す」シリーズの第2回です。 第1回はこちら insightwatchのセキュリティチェックでオールグリーンを目指す（その1: CISベンチマーク IAM設定編） 今回は「CIS 2. Logging」の対処を行なっていきます。名前のとおりログ周りの設定となります。 項目数は9項目と少ないのですが、きちんとログを取るため「全リージョンで設定を有効にする」という要件の項目が複数あり、対応はなかなか大変でした・・・ 最初のチェック結果 このパートの最初の結果は以下の通りです。9項目中注意4・重要3の指摘がありました。 以下、指摘事項の対処を行なっていきます。 CIS 2.2 CloudTrailログファイルの検証が有効化されていること CloudTrailのログファイルが変更や削除を検知する整合性
Grafana Loki で CloudNative なロギングをはじめよう！ / Let's begin cloud native logging with Grafana Loki!
Grafana Loki で CloudNative なロギングをはじめよう！ / Let's begin cloud native logging with Grafana Loki!
新しいダッシュボードで、GKE と GCE のロギング使用状況データを簡単に分析 | Google Cloud 公式ブログ
※この投稿は米国時間 2021 年 4 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。 システムやアプリケーションのログは、運用担当者や開発者がトラブルシューティングを行ったり、アプリケーションを正常な状態に保ったりするために欠かせないデータを提供してくれます。Google Cloud では、サービスのログデータを自動的に取得し、Cloud Logging や Cloud Monitoring で参照できるようにしています。しかし、利用するサービスが増えるのに伴って、ログデータの格納に必要な予算の見極めや、複数のプロジェクトを対象とした詳細分析が難しくなってくることがあります。このような問題に対処するため、本日、オープンソースの JSON ダッシュボード一式が公開されました。これらを Cloud Monitoring にインポートすることで、ロギングのボリュ
適当なディレクトリを作成し、composerを使用してmonologのインストールを行います。 $ composer require monolog/monolog インストール完了後、composer.jsonを確認するとインストールしたmonologのバージョンを確認することができます。 { "require": { "monolog/monolog": "^1.24" } } ログファイルへの書き出し(サンプルコード利用) インストールが完了したので、monologのGitHubにあるサンプルのコードを利用して動作確認を行ってみます。 monologをインストールしたディレクトリの中にtest.phpという名前のファイルを作成し以下を記述します。 <?php require 'vendor/autoload.php'; use Monolog\Logger; use Monolog\
OCI ロギングにログ出力できるツールを作った。
From f7579616910333a45cf7014066d015c3d0617a9c Mon Sep 17 00:00:00 2001 From: Yasuhiro Matsumoto <mattn.jp@gmail.com> Date: Wed, 15 Dec 2021 23:14:19 +0900 Subject: [PATCH] Fix sdkTimeFormat OCI server accept millisecond not nanosecond --- common/helpers.go | 4 ++-- common/http_test.go | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/common/helpers.go b/common/helpers.go i
概要 最近急にクラウドネイティブ界隈で話題になっているらしいロギングツールのLokiをDockerで試してみた。 コンテナのロギングと言えば今のところEFKスタック(Elasticsearch + Fluentd + Kibana)が一般的だが、個人的な開発環境や遊び環境だとElasticsearchが重いせいでEFKを使うことに抵抗があった。しかし、Lokiはちょっと使ってみた感じだと全然リソース消費が気にならず、シンプルでお手軽に導入できることからDockerの開発環境にはとりあえず入れておいた方がいいレベルのものになるかもしれない。 まだバージョン1.0ではなく、今後はPrometheusとも連携できるようになるようだが、個人的に使う分には現状でも十分役立ちそう。 構築 DockerにLokiのプラグインをインストールする 各コンテナがログをLokiへ転送するように設定する ログ収集
マルチアカウント環境での AWS Session Manager ロギングガードレールの実装 | Amazon Web Services
Amazon Web Services ブログ マルチアカウント環境での AWS Session Manager ロギングガードレールの実装 オーストリアの著名な銀行グループである Raiffeisen Bank International (RBI) は、マルチアカウントで AWS 環境を利用しています。これにより、製品チームは、集中管理されたセキュリティガードレールの範囲内で、新しい顧客機能を迅速に構築およびテストできます。これらのガードレールの1つでは、組織全体の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに対して確立されたすべてのセッションを一元的にロギングする必要があります。これにより、RBI のセキュリティチームは、組織全体のユーザーアクティビティの傾向を分析できるだけでなく、脅威検知、インシデント対応、フォレンジック、ログ
Cloudflare AI Gatewayを利用して、Amazon Bedrockを使ったAPIの利用状況の可視化、分析、ロギングできるか試してみた | DevelopersIO
Cloudflare AI Gatewayを利用して、Amazon Bedrockを使ったAPIの利用状況の可視化、分析、ロギングできるか試してみた どうも！オペレーション部の西村祐二です。 以前、Hono + Cloudflare Workers + AWS SDK for JavaScript v3 + Amazon Bedrockの構成でAIモデルの動作確認用のAPIを作りました。 Hono + Cloudflare Workers + AWS SDK for JavaScript v3の構成でAmazon Bedrockが利用できるか試してみた | DevelopersIO 今回このAPIに対して、AIアプリケーションの利用状況を可視化、分析、キャッシュ、生成された回答のロギングなどの環境を提供するCloudflare AI Gatewayを試してみたいと思います。 Cloudfl
Fargate + cloudwatch eventでcronシステム ロギング設計編 - Sionの技術ブログ
前回のお話 Fargate + cloudwatch eventでcronシステム構築 - Sionの技術ブログ 技術 aws-cloudwatch-logging module: terraform module。kinesis firehose + lambda。（cloudwatch logsに書き込まれたらs3とdatadog logsに吐き出す） s3: 長期間保存するログを格納 datadog logs: リアルタイムな1ヶ月間のログを保管。障害対応用 詳細 loggingは1つのmoduleで作られます。 module "logging_cron" { source = "../../../../../modules/aws-cloudwatch-logging" cluster_name = "cron" s3_bucket = "xxxxxxxxxx" dd_tag_sy
セッションの内容 デバッグやゲームバランスの調整といった開発終盤における作業は、その性質上どうしても手探りになりがちです。 その作業を改善し効率化するために、『リングフィット アドベンチャー』の開発ではログに注目しました。 具体的には、ゲーム開発用にログを大量に流すことのできる「printf」、そしてそのログを収集・分析するためのツールを開発・活用しました。 本セッションでは『リングフィット アドベンチャー』の開発において、どのように「ゲーム開発のための printf」を開発し活用したか、ご紹介します。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Functions: Node.jsで重要度付きのロギング - Qiita
Rails on ECSな構成でFluent Bitを利用して快適なロギングを実現する
Kubernetesトラブル原因特定を容易にするロギング強化機能 富士通のエンジニアが考えたその課題と解決策
運用を意識したGo言語でのエラーハンドリング/ロギング - Qiita
Google Functions & Node.js: winstonで高レベルなロギングをする方法 - Qiita
GoのロギングライブラリzapのTips - Carpe Diem
Docker Engine 20.10リリース：cgroups v2とデュアルロギングをサポート
Azure App Service でエラーを BLOB にロギングする - Qiita
ECS Execのロギングに関して | DevelopersIO
PHPのロギングmonologを理解する | アールエフェクト
DockerコンテナのロギングにGrafana＋Lokiを試してみた - Qiita
『リングフィット アドベンチャー』のロギングツール開発～ゲーム開発のために「printf」を作り直す～