In today’s digital landscape, where applications and services are more intertwined than ever, the need for robust monitoring and alerting mechanisms cannot be overstated. This is particularly true for pivotal architectural components like the Flex Gateway, which acts as the linchpin for both internal and external service communication. For architects, consultants, and administrators, understanding how to effectively monitor and alert within this framework is key to maintaining system integrity and performance.
Purpose of the Asset
The asset provides a foundational guide for those embarking on the integration of Monitoring and Alerting for the Flex Gateway. It serves as a valuable resource to quickly understand the available options and approaches, and how they can be implemented in a real-world scenario.
Audience Utility
- Architects: Gain insights into how the Flex Gateway can be effectively monitored within the broader context of your organization’s IT landscape.
- Consultants: Develop informed strategies to advise on the deployment of the Flex Gateway, ensuring robust monitoring and alerting capabilities are incorporated from the outset.
- Administrators: Acquire the necessary knowledge to configure and maintain the Flex Gateway, adhering to best practices in monitoring and alerting.
Observed Architecture: Under the Hood
The Flex Gateway is built with several core components that are essential for its operation and, consequently, for its monitoring:
The key component here is Fluent Bit, an open-source log shipper and processor, designed with performance and low resource consumption in mind, which is already a proven, well-established solution for resource-constrained environments like embedded Linux and gateways (also used in Runtime Fabric).
So to have a good understanding of the Flex Gateway’s logging features and configuration, one would have to first familiarise with Fluent Bit:
https://docs.fluentbit.io/manual
Also pictured above are some of the options for log shipping which can be configured:
- Anypoint Monitoring: out-of-the-box configuration when installing Flex GW in Connected Mode (covered in next section)
- Third-party (Enterprise) Monitoring: Quite common for bigger MuleSoft Customers is to use an Enterprise solution, like Splunk or ELK for monitoring and alerting, in which case the Flex Gateway can be configured to forward the log events to the respective system.
- Controller/Agent: This is the command center for the Flex Gateway, handling the deployment and management of policies. Monitoring at this level is crucial to ensure that the gateway is enforcing the intended policies correctly.
- Envoy: As the proxy that routes the traffic, Envoy’s logs provide a wealth of information regarding the nature and volume of the traffic passing through the Flex Gateway. Monitoring Envoy can alert administrators to potential issues such as spikes in traffic or unauthorized access attempts.
- FluentBit: This is an open-source log processor and forwarder that allows the gateway to unify logging across different sources and destinations. It is the linchpin for ensuring that the logs are streamlined and sent to the appropriate monitoring tools.
On the upper tier of the architecture, we see the Anypoint Platform Control Plane, which integrates with the Flex Gateway through Anypoint Monitoring. This integration allows for HTTP data to be ingested, providing a high-level view of the system’s health and performance.
Integration with Enterprise Monitoring Tools
The gateway’s architecture is designed to be agnostic with respect to the choice of monitoring tools. It can seamlessly integrate with a variety of enterprise monitoring solutions, such as Sumo Logic, Splunk, and ELK. This flexibility is key for organizations that may already have a preferred monitoring stack.
Alerting Strategy
A critical component of monitoring is the ability to alert the responsible teams when something goes awry. The Flex Gateway architecture should be configured to trigger alerts based on predefined conditions, such as error rates exceeding a certain threshold or response times degrading beyond acceptable levels.
Connected Mode vs. Local Mode
Another important aspect related to this topic is the difference between the Connected Mode and Local Mode installation of the Flex Gateway.
Connected Mode: Automated and Integrated Monitoring
In Connected Mode, the Flex Gateway is automatically configured to connect to the HTTP Ingest of the Anypoint Monitoring. Further configuration, cannot yet be made via the Anypoint UI or Platform APIs, but this is on the roadmap and the Product Team has shared internally a mock of the UI.
-
Automatic Configuration: The gateway, once in Connected Mode, is pre-configured to connect with Anypoint Monitoring’s HTTP Ingest. This eases the initial setup and quickly aligns the gateway with the monitoring tools.
-
Future UI/Platform API Configurations: While current configurations in Connected Mode are somewhat limited, MuleSoft’s roadmap includes enhanced UI and API configurations. This forthcoming feature, as indicated by the internal mockups shared by the Product Team, promises a more granular and intuitive management interface.
Local Mode: Independent but Limited Monitoring
In Local Mode, the Flex Gateway is mostly disconnected from the Anypoint Platform (except for licensing checks, and commercial-related metrics). So no connectivity with Anypoint Monitoring and no options, current or future, for configuring the Flex Gateway via the platform. Monitoring and Alerting, in this case, is only possible using a 3rd party tool as mentioned previously.
-
Limited Platform Integration: When operating in Local Mode, the gateway is mostly autonomous from the Anypoint Platform, relying on it only for licensing and commercial metrics.
-
Third-Party Monitoring Necessity: Without the integration with Anypoint Monitoring, users must turn to third-party tools like Sumo Logic, Splunk, or ELK for monitoring and alerting needs.
Configuration: Leveraging YAML for Customization
In both modes, configurations are primarily handled through YAML files, which dictate the gateway’s behavior:
-
Fluent Bit Configuration: Although Fluent Bit traditionally does not support YAML configuration directly, Flex Gateway cleverly circumvents this by auto-generating the native Fluent Bit configuration file from the gateway’s YAML settings. This allows for a more user-friendly configuration experience.
-
Output-Only Configuration: Presently, within Flex Gateway’s scope, you can only configure the Output settings for Fluent Bit. This means deciding where and how the logs are sent, with support for multiple concurrent outputs.
Log Management: Defaults and Customizations
Flex Gateway’s approach to logs is to provide sensible defaults while allowing for customization:
-
Runtime Logs: By default, runtime logs are enabled, capturing the operational statistics of the gateway.
-
Access Logs: To enable access logs, you must apply the Message Logging policy on a per-API basis. This policy binding ensures that you have control over which APIs are monitored at the access log level.
Strategic Considerations for Monitoring Flex Gateway
Choosing between Connected Mode and Local Mode in Flex Gateway boils down to the degree of integration and autonomy required by your organization. Connected Mode offers a more integrated, albeit currently less customizable, monitoring environment. Local Mode demands more independence and the necessity for third-party monitoring solutions.
In either case, understanding the configuration process and the role of Fluent Bit within the Flex Gateway’s architecture is crucial. As Flex Gateway continues to evolve, particularly with the anticipated UI and platform API enhancements, administrators will gain even greater control over their monitoring and alerting strategies, ensuring that their gateways operate optimally within the broader IT ecosystem.
