HttpClient 使用 URL Parameters (Query Strings) 的方式 前陣子有個跟其他系統介接的需求，因為手上工作太滿，先由前端的同事使用 Node.js 開發，過陣子再接手改用 C# 開發；其中有個功能需要 post 幾

使用 sysbench 來取得 ProxySQL 效能差異 在之前筆記 使用 ProxySQL 來簡化 MySQL 的讀寫分離 提到需要進行壓力測試取得透過 ProxySQL 與直接存取 MySQL 的效能數據差來評估是否採用 ProxySQL 今天就來紀錄使

使用 ProxySQL 來簡化 MySQL 的讀寫分離 隨著系統使用者愈來愈多，對於 MySQL 的存取量也跟提高許多，為了增加系統整體 capacity，首先打算從 MySQL 著手調整起，在經過

RabbitMQ Shovel 將訊息同步至不同 Vhost (Cluster) 之前筆記 RabbitMQ 為不同帳號設定不同 topic 權限 紀錄到為了讓不同 User 在可以在收發訊息時可以控制存取權限，當時有提到透過在同個 virtual host 下設

[Zipkin] 使用 OpenTelemetry 來追蹤 ASP.NET Core 上的 gRPC 呼叫 之前筆記 [Zipkin] 使用 OpenTelemetry 來追蹤 ASP.NET Core 紀錄到使用 OpenTelemetry 搭配 Zipkin 來追蹤 ASP.NET Core 也曾在 .NET Core 上使用 Jaeger 追蹤 gRPC 呼叫 紀錄使用 OpenTracing 來追蹤 gRPC 呼叫，之前筆

[Jaeger] 使用 OpenTelemetry 來追蹤 ASP.NET Core 上的 gRPC 呼叫 之前筆記 [Jaeger] 使用 OpenTelemetry 來追蹤 ASP.NET Core 紀錄到使用 OpenTelemetry 搭配 Jaeger 來追蹤 ASP.NET Core 也曾在 .NET Core 上使用 Jaeger 追蹤 gRPC 呼叫 紀錄使用 OpenTracing 來追蹤 gRPC 呼叫，因為目

[Zipkin] 使用 OpenTelemetry 來追蹤 ASP.NET Core 這是延續之前筆記 [Jaeger] 使用 OpenTelemetry 來追蹤 ASP.NET Core 進行嘗試的筆記，過去使用 OpenTracing 時因為 Zipkin 與 .NET Core 的整合程式較低，設定上繁瑣許多，加上無法處理主要

[Jaeger] 使用 OpenTelemetry 來追蹤 ASP.NET Core 前幾天看到微軟官方部落格 OpenTelemetry .NET reaches v1.0 公開了 OpenTelemetry .NET v1.0 版，之前在研究 OpenTracing 也有考慮過 OpenTelemetry 畢竟大一統的規格未來性跟前景應該都比較好，但當時相

使用 Elasticdump 來匯入與匯出 Elasticsearch index 外網的測試環境因為有外部服務介接的關係，有較多機會出現 exception，為了方便 debug，所以想要將外網的 log 倒回內

RabbitMQ 為不同帳號設定不同 Queue 權限 同事在新功能的架構設計時想要讓不同 user 在 MQ 存取時可以有權限的概念，但以團隊之前使用的 Kafka 至少就我個人所知是無法達成的，

ASP.NET Core gRPC 的 Secure 與 Insecure 不同做法 之前筆記 ASP.NET Core gRPC 使用自發憑證時在 macOS 的特別處理 紀錄到如何在 macOS 與 container 間使用不同 port 與 protocol 來建立 gRPC service，當時查資料看到也許

ASP.NET Core gRPC 使用自發憑證時在 macOS 的特別處理 之前筆記 ASP.NET Core gRPC 使用自發憑證 紀錄到使用自發憑證來為 ASP.NET Core gRPC service 加上 tls，透過新的做法看似可以正確在 container 內執行，只

ASP.NET Core gRPC 使用自發憑證 距之前筆記 讓 container 中的 ASP.NET Core 也有憑證 也不過幾個月時間，最近想要搭配 Kubernetes 發行憑證給 ASP.NET Core 使用 透過 Kubernetes 的 cert-manager 使用自簽憑證，想不到一直不通，從

確認 MongoDB 驗證機制 前幾天在進行每日 server 狀態異常檢查時，偶然發現 MongoDB 的錯誤 log 很多，進一步整理後統整出每個 application 連線認證都會先出現一次 SCRAM-SHA-256 認證失敗之後才會出現

ASP.NET Core 避免工作執行到一半強制被關閉 最近同事反應部份 application 在不同環境間，有 stop log 沒有正常紀錄下來的情況，雖然只是 log，但很有可能就連原本預期執行完畢