On March 20, 2023, OpenAI’s ChatGPT service was interrupted for a period of time. Subsequently, OpenAI published an announcement March 20 ChatGPT outage: Here’s what happened explaining the ins and outs of this incident. In the announcement, OpenAI detailed the scope of impact, remediation strategies, some technical details, and improvement measures for this incident, which is quite worth learning from.

The specific timeline of this incident handling is also publicly available on ChatGPT Web Interface Incident, as shown in the following image:

This fault was caused by a bug in Redis’s Python client, and there are discussions about this bug on Github. The fixing process of this bug was not smooth, with many discussions and fix attempts, such as Issue 2624, PR 2641, Issue 2665, PR 2695. After reading these, I still couldn’t fully understand the fix here, so I had to delve into the code to see what exactly happened with the bug’s cause and fixing process, and organize it into this article.

Large language models (LLMs) like ChatGPT have made significant breakthroughs this year and are now playing important roles in many fields. As prompts serve as the medium for interaction between humans and large language models, they are also frequently mentioned. I’ve written several articles discussing best practices for prompts in ChatGPT, such as the first one: GPT4 Prompting Technique 1: Writing Clear Instructions.

However, as our understanding and use of these large language models deepen, new issues are beginning to surface. Today, we’ll explore one important issue: prompt attacks. Prompt attacks are a new type of attack method, including prompt injection, prompt leaking, and prompt jailbreaking. These attack methods may lead to models generating inappropriate content, leaking sensitive information, and more. In this blog post, I will introduce these attack methods in detail to help everyone gain a better understanding of the security of large language models.

We all know that monitoring function execution time is crucial when developing and maintaining backend services. Through monitoring, we can promptly identify performance bottlenecks, optimize code, and ensure service stability and response speed. However, traditional methods often involve adding statistics to the code and reporting them, which, although effective, typically only target functions considered to be on the critical path.

Suppose at some point, we suddenly need to monitor the execution time of a function that wasn’t a focus of attention. In this case, modifying the code and redeploying the service can be a cumbersome and time-consuming task. This is where eBPF (extended Berkeley Packet Filter) and BCC (BPF Compiler Collection) come in handy. By using eBPF, we can dynamically insert probes to monitor function execution time without modifying code or redeploying services. This not only greatly simplifies the monitoring process but also reduces the impact on service performance.

In the following article, we will detail how to use eBPF BCC to analyze service function execution time non-intrusively, and demonstrate its powerful capabilities through practical examples.