Troubleshoot GKE apps faster with monitoring data in Cloud Logging

When you’re troubleshooting an application on Google Kubernetes Engine (GKE), the more context that you have on the issue, the faster you can resolve it. For example, did the pod exceed it’s memory allocation? Was there a permissions error reserving the storage volume? Did a rogue regex in the app pin the CPU? All of these questions require developers and operators to build a lot of troubleshooting context. Cloud Monitoring data for GKE in Cloud LoggingTo make it easier to troubleshoot GKE apps, we’ve added contextual Cloud Monitoring data accessible right from Cloud Logging. With this new feature, you can easily see the relevant pod, node and cluster events, metrics, alerts, and SLOs right from the log line itself. Additionally, the data loaded for a specific log entry is scoped to the Kubernetes resource, which saves you valuable time while investigating an app error.Today’s announcement builds on other recent integrations including the addition of a logs tab nested in the details page of each of your GKE resources and combining metrics and logs in the GKE Dashboard in Monitoring. Now, wherever you start your troubleshooting journey – in Monitoring, Logging or GKE – you have the observability data at your fingertips. For example, if you’re troubleshooting a GKE app error in Cloud Logging and looking at the app logs, you can now view the metric charts for container restarts, uptime, memory, CPU and storage without leaving the log entry. Active alerts are highlighted on the alerts tab, which can provide helpful context for troubleshooting. This unique and integrated experience brings together critical log and metric data for the specific Kubernetes resource where your app is running.Viewing Monitoring data for GKE from a log lineFrom a k8s_container, k8s_pod, k8s_node, or k8s_cluster log, select the blue chip with the resource.labels resource name and then select “View Monitoring details” to access an integrated metrics panel directly from the Logs Explorer. Selecting “View in GKE” opens the detailed view of the GKE resource in the Cloud Console on a new tab.The metrics panel provides a lot of contextual data including alerts, Kubernetes events and metrics related to the GKE resource.Alerts Alerts triggered by the GKE resource are displayed under the alerts tab. The color-coded alert status provides an easy way to see ongoing, acknowledged and closed incidents. Selecting “VIEW INCIDENT” opens the incident details in Cloud Monitoring. If you want to create a new alert, use the link to create a brand new alert policy.Kubernetes events for clusters and podsThe metrics panel provides select events for clusters and pods.  For each event, the name, associated resource and a link to view/copy the log message are displayed. Kubernetes events can provide important information to help determine the root cause of an issue. For example, if a FailedScheduling event is displayed, this can quickly guide troubleshooting to check the resources available to the Kubernetes resource.Metrics for containers, pods and nodesThe metrics tab contains metrics bundles for container (default), pod and node metrics collected from the GKE cluster and reported in Cloud Monitoring. Each metric bundle offers pre-built charts that can be selected to view the CPU, memory, storage and container restarts. For example, by looking at the CPU or memory, you can determine whether there were any spikes in the metrics for the Kubernetes resources.More to comeWe’re committed to making Google Cloud’s operations suite the best place to troubleshoot your GKE apps. We’ve integrated logs directly into GKE resource details pages and built a specialized integrated GKE Dashboard, all to make it easier to troubleshoot GKE apps. However, there is still more coming and we’re already working hard to add new features to the metrics panels to surface even more context for troubleshooting GKE apps.Get started todayIf you haven’t already, to get started with Cloud Logging and Cloud Monitoring on GKE, viewdocumentation, watch a quick video on troubleshooting services on GKE and join the discussion in our new Cloud Operations page on the Google Cloud Community site.Related ArticleGKE operations magic: From an alert to resolution in 5 stepsTeams operating microservices increasingly rely on metrics, logs, and traces to identify and troubleshoot problems. The GKE Dashboard bri…Read Article
Quelle: Google Cloud Platform

Zero trust with reverse proxy

A reverse proxy stands in front of your data, services, or virtual machines, catching requests from anywhere in the world and carefully checking each one to see if it is allowed.In order to decide (yes or no) the proxy will look at who and what.Who are you (the individual making the request)? What is your role? Do you have access permission (authorization)?What device are you using to make the request? How healthy is your device right now? Where are you located? At what time are you making the request?This issue of GCP Comics presents an example of accessing some rather confidential data from an airplane, and uses that airplane as a metaphor to explain what the proxy is doing.Click to enlargeReverse proxies work as part of the load balancing step when requests are made to web apps or services, and they can be thought of as another element of the network infrastructure that helps route requests to the right place. No one can access your resources unless they meet certain rules and conditions.If a request is invalid or doesn’t meet the necessary criteria set by your administrators, either because it is from an unauthorized person or an unsafe device, then the proxy will deny the request.Why might the proxy say no to my request? When assessing the user making the request, denial of access could be due to reasons such as:I’m in Engineering, but I am trying to access Finance data.I’m not even a part of the company.My job changed, and I lost access.Looking at the device originating the request, the proxy could deny access due to a number of factors, such as:Device operating system out of dateMalware detectedDevice is not reporting inDisk encryption missingDevice doesn’t have screen lockLeveraging identity and device information to secure access to your organization’s resources improves your security posture.ResourcesTo learn more about proxies and Zero Trust, check out the following resources:Overview of Identity-Aware ProxyExtending Zero Trust models to the webCreating a device-based access levelHow to set up a proxy for on-premises appsBeyondCorp Enterprise Quickstart GuideWant more GCP Comics? Visit gcpcomics.com & follow us on medium pvergadia & max-saltonstall, and on Twitter at @pvergadia and @maxsaltonstall. Be sure not to miss the next issue!Related ArticleWhat is zero trust identity security?A zero trust network is one in which no person, device, or network enjoys inherent trust. All trust, which allows access to information, …Read Article
Quelle: Google Cloud Platform

AWS Storage Gateway unterstützt jetzt Quest NetVault Backup 13 auf Tape Gateway

AWS Storage Gateway unterstützt jetzt Quest NetVault Backup 13 auf Tape Gateway. Dadurch können Sie Daten aus Quest NetVault Backup in AWS sichern und archivieren, ohne Ihre Backup-Workflows zu ändern. Mit dieser Ankündigung unterstützt Tape Gateway Quest NetVault Backup 13, das auf Microsoft Windows Server 2012 R2 oder Microsoft Windows Server 2016 ausgeführt wird.
Quelle: aws.amazon.com

AWS Control Tower ist jetzt in Sao Paulo und Paris verfügbar und ermöglicht die Abwahl von Regionen

AWS Control Tower ist jetzt in 2 weiteren AWS-Regionen verfügbar: Südamerika (Sao Paulo) und Europa (Paris), was die Verfügbarkeit von AWS Control Tower auf 15 AWS-Regionen erweitert. Wir kündigen die AWS Control Tower Region Deselection an, mit der Sie den geografischen Fußabdruck Ihrer AWS Control Tower-Ressourcen effizient verwalten können. Sie können jetzt die Regionen abwählen, die Sie nicht mehr von AWS Control Tower verwalten lassen möchten. Damit haben Sie die Möglichkeit, Compliance- und regulatorische Belange zu berücksichtigen und gleichzeitig die Kosten auszugleichen, die mit der Expansion in zusätzliche Regionen verbunden sind.
Quelle: aws.amazon.com

Amazon EKS unterstützt jetzt Multus

Amazon Elastic Kubernetes Service (EKS) unterstützt jetzt das Multus Container Networking Interface (CNI)-Plugin, mit dem Pods, die in EKS-Clustern laufen, mehrere Netzwerkschnittstellen anschließen können, um erweiterte Netzwerkkonfigurationen zu unterstützen.
Quelle: aws.amazon.com