The trouble with the new uretprobes

Post Syndicated from corbet original https://lwn.net/Articles/1005662/

A “uretprobe” is a dynamic, user-space tracepoint injected by the kernel
into a running process; this document
tersely describes their use. Among other things, uretprobes are used by
the perf utility to time function calls. The 6.11 kernel saw a
significant change to uretprobes that improved their performance, but that
change is also creating trouble for some users. The best way to solve the
problem is not entirely clear.

Luma AI’s Ray2 video model is now available in Amazon Bedrock

Post Syndicated from Channy Yun (윤석찬) original https://aws.amazon.com/blogs/aws/luma-ai-ray-2-video-model-is-now-available-in-amazon-bedrock/

As we preannounced at AWS re:Invent 2024, you can now use Luma AI Ray2 video model in Amazon Bedrock to generate high-quality video clips from text, creating captivating motion graphics from static concepts. AWS is the first and only cloud provider to offer fully managed models from Luma AI.

On January 16, 2025, Luma AI introduced Luma Ray2, the large–scale video generative model capable of creating realistic visuals with natural, coherent motion with strong understanding of text instructions. Luma Ray2 exhibits advanced capabilities as a result of being trained on Luma’s new multi-modal architecture. It scales to ten times compute of Ray1, enabling it to produce 5 second or 9 second video clips that show fast coherent motion, ultra-realistic details, and logical event sequences with 540p and 720p resolution.

With Luma Ray2 in Amazon Bedrock, you can add high-quality, realistic, production-ready videos generated from text in your generative AI application through a single API. Luma Ray2 video model understands the interactions between people, animals, and objects, and you can create consistent and physically accurate characters through state-of-the-art natural language instruction understanding and reasoning.

You can use Ray2 video generations for content creation, entertainment, advertising, and media use cases, streamlining the creative process, from concept to execution. You can generate smooth, cinematic, and lifelike camera movements that match the intended emotion of the scene. You can rapidly experiment with different camera angles and styles and deliver creative outputs for architecture, fashion, film, graphic design, and music.

Let’s take a look at the impressive video generations by Luma Ray2 that Luma has published.

Get started with Luma Ray2 model in Amazon Bedrock
Before getting started, if you are new to using Luma models, go to the Amazon Bedrock console and choose Model access on the bottom left pane. To access the latest Luma AI models, request access for Luma Ray2 in Luma AI.

To test the Luma AI model in Amazon Bedrock, choose Image/Video under Playgrounds in the left menu pane. Choose Select model, then select Luma AI as the category and Ray as the model.

For video generation models, you should have an Amazon Simple Storage Service (Amazon S3) bucket to store all generated videos. This bucket will be created in your AWS account, and Amazon Bedrock will have read and write permissions for it. Choose Confirm to create a bucket and generate a video.

I will generate a 5-second video with 720P and 24 frames per second with 16:9 aspect ratio for my prompt.

Here is an example prompt and generated video. You can download it stored in the S3 bucket.
a humpback whale swimming through space particles

Here are another featured examples to demonstrate Ray2 model.

Prompt 1: A miniature baby cat is walking and exploring on the surface of a fingertip

Prompt 2: A massive orb of water floating in a backlit forest

Prompt 3: A man plays saxophone by @ziguratt

Prompt 4: Macro closeup of a bee pollinating

To check out more examples and generated videos, visit the Luma Ray2 page.

By choosing View API request in the Bedrock console, you can also access the model using code examples in the AWS Command Line Interface (AWS CLI) and AWS SDKs. You can use luma.ray-v2:0 as the model ID.

Here is a sample of the AWS CLI command:

aws bedrock-runtime invoke-model \
    --model-id luma.ray-v2:0 \
    --region us-west-2 \
    --body "{\"modelInput\":{\"taskType\":\"TEXT_VIDEO\",\"textToVideoParams\":{\"text\":\"a humpback whale swimming through space particles\"},\"videoGenerationConfig\":{\"seconds\":6,\"fps\":24,\"dimension\":\"1280x720\"}},\"outputDataConfig\":{\"s3OutputDataConfig\":{\"s3Uri\":\"s3://your-bucket-name\"}}}"
     invoke-model-output.txt

You can use Converse API examples to generate videos using AWS SDKs to build your applications using various programming languages.

Now available
Luma Ray2 video model is generally available today in Amazon Bedrock in the US West (Oregon) AWS Region. Check the full Region list for future updates. To learn more, check out the Luma AI in Amazon Bedrock product page and the Amazon Bedrock Pricing page.

Give Luma Ray2 a try in the Amazon Bedrock console today, and send feedback to AWS re:Post for Amazon Bedrock or through your usual AWS Support contacts.

— Channy

CCN releases guide for Spain’s ENS landing zones using Landing Zone Accelerator on AWS

Post Syndicated from Tomás Clemente Sánchez original https://aws.amazon.com/blogs/security/ccn-releases-guide-for-spains-ens-landing-zones-using-landing-zone-accelerator-on-aws/

Spanish version »

The Spanish National Cryptologic Center (CCN) has published a new STIC guide (CCN-STIC-887 Anexo A) that provides a comprehensive template and supporting artifacts for implementing landing zones that comply with Spain’s National Security Framework (ENS) Royal Decree 311/2022 using the Landing Zone Accelerator on AWS. Spain’s ENS establishes a common framework of basic principles and requirements of security for Spanish public sector organizations and their service providers, including supply chain providers. Over the years, the collaboration between Amazon Web Services (AWS) and the CCN has resulted in the publication of eight secure configuration guides (Series STIC 887) that provide comprehensive advice on the configuration of AWS services to align with the ENS. The guide CCN-STIC-887 Anexo A is the last addition to this series.

The centerpiece of this new guide is the ENS template for the Landing Zone Accelerator on AWS (LZA ENS). A landing zone serves as the initial setup of an organization’s cloud account or environment, including the implementation of security controls, access management, and compliance frameworks. The Landing Zone Accelerator on AWS is a powerful open source tool created by AWS for organizations that want to quickly customize and automate implementation of landing zones that align with AWS best practices and with regulatory compliance frameworks. This tool provides a comprehensive solution that, managed entirely by code, automatically configures over 35 AWS services using a simplified set of configuration files to manage and govern a multi-account environment, helping customers with highly regulated workloads and complex compliance requirements.

The CCN-STIC-887 Anexo A guide focuses on helping organizations implement landing zones that meet ENS security requirements from the ground up. It offers detailed instructions and templates for establishing a landing zone—the foundational infrastructure required for a secure, well-managed cloud environment—and a control matrix to demonstrate compliance with ENS controls.

Key components covered in the STIC 887H guide include:

  • Logging and monitoring: LZA ENS performs a default and scaled activation of the necessary logging and monitoring services required to meet ENS monitoring requirements in AWS services (such as AWS CloudTrail, Amazon CloudWatch, AWS Security Hub, and Amazon GuardDuty).
  • Access control: LZA ENS implements the management of identity and access management methods and policies at scale, which are aligned with the access control requirements of the ENS in a centralized manner using AWS IAM Identity Center.
  • Asset management: By default, LZA ENS activates inventory functions and resource and inventory tagging policies (for example, AWS Config) that support ENS asset management controls in the services.
  • Network topology: LZA ENS can be used to deploy a centralized network topology in accordance with ENS network security controls.
  • Cryptography: The encryption service activation capabilities built into LZA ENS can help organizations align with ENS data protection standards through mandatory encryption at rest, enforcement mechanisms with AWS Key Management Service (AWS KMS), and monitoring mechanisms to detect unencrypted data and communications with AWS Config rules.
  • Compliance and data residency: LZA ENS includes control policies to promote the use of AWS services with the ENS High certification and to provide processing on AWS in accordance with customers’ data residency requirements.

Organizations that require specific customizations to fully meet the requirements of the ENS can use LZA ENS to quickly modify and add customized security controls and then execute the scaled deployment of these controls to their accounts in the landing zone. One of the customizations included in LZA ENS is the integration of the open source security tool Prowler with Security Hub as an automated auditing tool with the objective of providing an up-to-date view of compliance with ENS controls. In addition, by providing a base designed for security and the flexibility to add custom controls, LZA ENS can support the process of achieving and maintaining compliance with the ENS in the AWS Cloud environment.

The CCN-STIC-887 Anexo A guide represents an important step forward in standardizing secure cloud deployments for Spanish public sector organizations and those working with government entities. This publication demonstrates the AWS commitment to support organizations in their secure cloud adoption journey while maintaining compliance with national security standards.
 


Spanish version

CCN publica la guía para las Zonas de Aterrizaje del ENS con AWS Landing Zone Accelerator

El Centro Criptológico Nacional de España (CCN) ha publicado una nueva guía STIC (CCN-STIC-887 Anexo A) que proporciona una plantilla de código y material de soporte para implementar zonas de aterrizaje (o landing zones) que cumplan con el Esquema Nacional de Seguridad del Real Decreto 311/2022 (ENS) mediante el Landing Zone Accelerator on AWS. El ENS establece un marco común de principios básicos, requisitos y medidas de seguridad para las organizaciones del sector público español y sus prestadores de servicios, incluyendo la cadena de suministro. A lo largo de los años, la colaboración entre Amazon Web Services (AWS) y el CCN se ha traducido en la publicación de ocho guías de configuración segura (serie STIC 887) que proporcionan consejo sobre la configuración de los servicios de AWS para alinearse con el ENS. La guía CCN-STIC-887 Anexo A es la última incorporación a esta serie.

La pieza central de la nueva guía es la plantilla ENS para el AWS Landing Zone Accelerator (LZA ENS). Una zona de aterrizaje (landing zone) sirve como la configuración inicial del entorno en la nube de una organización, e incluye la implementación inicial de controles de seguridad, la administración del acceso y los marcos de cumplimiento. El AWS Landing Zone Accelerator es una potente herramienta de código abierto creada por AWS para las organizaciones que desean implementar de forma rápida, segura, personalizada y automatizada zonas de aterrizaje alineadas con las prácticas recomendadas de AWS, así como con marcos de conformidad. Esta herramienta proporciona una solución integral que, mediante código, configura automáticamente más de 35 servicios de AWS con un conjunto simplificado de archivos de configuración para administrar y gobernar un entorno multicuenta, lo que ayuda a los clientes con cargas de trabajo altamente reguladas y requisitos de cumplimiento normativo.

La guía CCN-STIC-887 Anexo A se centra específicamente en ayudar a las organizaciones a implementar desde cero zonas de aterrizaje que cumplan con los requisitos de seguridad del ENS. Ofrece instrucciones y plantillas detalladas para establecer una zona de aterrizaje – la infraestructura básica necesaria para un entorno de nube seguro y bien administrado – así como una matriz de control para demostrar el cumplimiento de los controles del ENS.

Los componentes clave incluidos en la guía STIC 887H incluyen:

  • Registro y monitoreo: LZA ENS realiza una activación por defecto y a escala de los servicios de registro y monitoreo necesarios en AWS (como AWS CloudTrail, Amazon CloudWatch, AWS Security Hub, y AWS GuardDuty) para cumplir con los requisitos de monitoreo del ENS.
  • Control de acceso: LZA ENS implementa los métodos y políticas de administración de identidades y accesos a escala, que se alinean con los requisitos de control de acceso del ENS de manera centralizada mediante AWS IAM Identity Center..
  • Administración de activos: De forma predeterminada, el LZA ENS activa las funciones de inventario y las políticas de etiquetado de recursos e inventario (por ejemplo AWS Config) que soportan los controles de administración de activos del ENS.
  • Topología de red: LZA ENS se puede utilizar para implementar una topología de red centralizada de acuerdo con los controles de seguridad de red ENS.
  • Criptografía: las capacidades de activación de cifrado integradas en la LZA ayudan a organizaciones a alinearse con los estándares de protección de datos del ENS mediante el cifrado obligatorio en reposo, los mecanismos de aplicación con AWS Key Management Service (AWS KMS) y los mecanismos de supervisión para detectar datos y comunicaciones no cifrados con las reglas de AWS Config.
  • Cumplimiento y residencia de datos: LZA ENS incluye políticas de control para promover el uso de los servicios de AWS con la certificación del ENS Alto y realizar el procesamiento en AWS de acuerdo con los requisitos de residencia de datos del cliente.

Las organizaciones que requieren personalizaciones específicas para cumplir plenamente los requisitos del ENS pueden usar el LZA ENS para modificar rápidamente y añadir fácilmente controles de seguridad personalizados y ejecutar la implementación a escala de estos controles en sus cuentas de la zona de aterrizaje. Una de las personalizaciones que hemos incluido en el LZA ENS es la integración de Prowler con AWS Security Hub como una herramienta de auditoría automatizada, con el objetivo de proporcionar una visión actualizada del cumplimiento de los controles ENS de una manera fácil y eficaz. Además, al proporcionar una base diseñada para la seguridad y la flexibilidad de agregar controles personalizados, LZA ENS puede ayudar durante el proceso de obtener la conformidad con el ENS en el entorno de nube de AWS.

La guía CCN-STIC-887 Anexo A representa un importante paso adelante en la estandarización de las implementaciones seguras en la nube para las organizaciones del sector público español. Esta publicación demuestra el compromiso de AWS de apoyar a las organizaciones en su proceso de adopción segura de la nube, manteniendo al mismo tiempo el cumplimiento de las normas de seguridad nacionales.

 
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Tomás Clemente Sánchez
Tomás Clemente Sánchez

Tomás Clemente Sánchez is a Principal Security Solutions Architect at AWS, based in Madrid, Spain. He works advising highly regulated customers in public sector and national security organizations on the implementation of cloud security technologies and data protection frameworks. Outside of work, he is addicted to cinema and sci-fi novels, a rugby fan, and a scuba diver.

Access Amazon S3 Iceberg tables from Databricks using AWS Glue Iceberg Rest Catalog in Amazon SageMaker Lakehouse

Post Syndicated from Srividya Parthasarathy original https://aws.amazon.com/blogs/big-data/access-amazon-s3-iceberg-tables-from-databricks-using-aws-glue-iceberg-rest-catalog-in-amazon-sagemaker-lakehouse/

Amazon SageMaker Lakehouse enables a unified, open, and secure lakehouse platform on your existing data lakes and warehouses. Its unified data architecture supports data analysis, business intelligence, machine learning, and generative AI applications, which can now take advantage of a single authoritative copy of data. With SageMaker Lakehouse, you get the best of both worlds—the flexibility to use cost effective Amazon Simple Storage Service (Amazon S3) storage with the scalable compute of a data lake, along with the performance, reliability and SQL capabilities typically associated with a data warehouse.

SageMaker Lakehouse enables interoperability by providing open source Apache Iceberg REST APIs to access data in the lakehouse. Customers can now use their choice of tools and a wide range of AWS services such as Amazon Redshift, Amazon EMR, Amazon Athena and Amazon SageMaker, in addition to third-party analytics engines that are compatible with Apache Iceberg REST specifications to query their data in-place.

Finally, SageMaker Lakehouse now provides secure and fine-grained access controls on data in both data warehouses and data lakes. With resource permission controls from AWS Lake Formation integrated into the AWS Glue Data Catalog, SageMaker Lakehouse lets customers securely define and share access to a single authoritative copy of data across their entire organization.

Organizations managing workloads in AWS analytics and Databricks can now use this open and secure lakehouse capability to unify policy administration and oversight of their data lake in Amazon S3. In this post, we will show you how Databricks on AWS general purpose compute can integrate with the AWS Glue Iceberg REST Catalog for metadata access and use Lake Formation for data access. To keep the setup in this post straightforward, the Glue Iceberg REST Catalog and Databricks cluster share the same AWS account.

Solution overview

In this post, we show how tables cataloged in Data Catalog and stored on Amazon S3 can be consumed from Databricks compute using Glue Iceberg REST Catalog with data access secured using Lake Formation. We will show you how the cluster can be configured to interact with Glue Iceberg REST Catalog, use a notebook to access the data using Lake Formation temporary vended credentials, and run analysis to derive insights.

The following figure shows the architecture described in the preceding paragraph.

Prerequisites

To follow along with the solution presented in this post, you need the following AWS prerequisites:

  1. Access to the Lake Formation data lake administrator in your AWS account. A Lake Formation data lake administrator is an IAM principal that can register Amazon S3 locations, access the Data Catalog, grant Lake Formation permissions to other users, and view AWS CloudTrail See Create a data lake administrator for more information.
  2. Enable full table access for external engines to access data in Lake Formation.
    • Sign into Lake Formation console as an IAM administrator and choose Administration in the navigation pane.
    • Choose Application integration settings and select Allow external engines to access data in Amazon S3 locations with full table access.
    • Choose Save.
  3. An existing AWS Glue database and tables. For this post, we will use an AWS Glue database named icebergdemodb, which contains an Iceberg table named person and data is stored in an S3 general purpose bucket named icebergdemodatalake.

  4. A user-defined IAM role that Lake Formation assumes when accessing the data in the above S3 location to vend scoped credentials. Follow the instructions provided in Requirements for roles used to register locations. For this post, we will use the IAM role LakeFormationRegistrationRole.

In addition to the AWS prerequisites, you need access to Databricks Workspace (on AWS) and the ability to create a cluster with No isolation shared access mode.

Set up an instance profile role. For instructions on how to create and set up the role, see Manage instance profiles in Databricks. Create customer managed policy named: dataplane-glue-lf-policy with below policies and attach the same to the instance profile role:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
               "Action": [
                "glue:UpdateTable",
                "glue:GetDatabase",
                "glue:GetDatabases",
                "glue:GetCatalog",
                "glue:GetCatalogs",
                "glue:GetPartitions",
                "glue:GetPartition",
                "glue:GetTable",
                "glue:GetTables"
            ],
            "Resource": [
                "arn:aws:glue:<aws_region>:<accountid>:table/icebergdemodb/*",
                "arn:aws:glue:<aws_region>:<accountid>:database/icebergdemodb",
                "arn:aws:glue:<aws_region>:<accountid>:catalog"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "lakeformation:GetDataAccess"
            ],
            "Resource": "*"
        }
    ]
}

For this post, we will use an instance profile role (databricks-dataplane-instance-profile-role), which will be attached to the previously created cluster.

Register the Amazon S3 location as the data lake location

Registering an Amazon S3 location with Lake Formation provides an IAM role with read/write permissions to the S3 location. In this case, you are required to register the icebergdemodatalake bucket location using the LakeFormationRegistrationRole IAM role.

After the location is registered, Lake Formation assumes the LakeFormationRegistrationRole role when it grants temporary credentials to the integrated AWS services/third-party analytics engines that are compatible(prerequisite Step 2) that access data in that S3 bucket location.

To register the Amazon S3 location as the data lake location, complete the following steps:

  1. Sign in to the AWS Management Console for Lake Formation as the data lake administrator .
  2. In the navigation pane, choose Data lake locations under Administration.
  3. Choose Register location.
  4. For Amazon S3 path, enter s3://icebergdemodatalake.
  5. For IAM role, select LakeFormationRegistrationRole.
  6. For Permission mode, select Lake Formation.
  7. Choose Register location.

Grant database and table permissions to the IAM role used within Databricks

Grant DESCRIBE permission on the icebergdemodb database to the Databricks IAM instance role.

  1. Sign in to the Lake Formation console as the data lake administrator.
  2. In the navigation pane, choose Data lake permissions and choose Grant.
  3. In the Principles section, select IAM users and roles and choose databricks-dataplane-instance-profile-role.
  4. In the LF-Tags or catalog resources section, select Named Data Catalog resources. Choose <accountid> for Catalogs and icebergdemodb for Databases.
  5. Select DESCRIBE for Database permissions.
  6. Choose Grant.

Grant SELECT and DESCRIBE permissions on the person table in the icebergdemodb database to the Databricks IAM instance role.

  1. In the navigation pane, choose Data lake permissions and choose Grant.
  2. In the Principles section, select IAM users and roles and choose databricks-dataplane-instance-profile-role.
  3. In the LF-Tags or catalog resources section, select Named Data Catalog resources. Choose <accountid> for Catalogs, icebergdemodb for Databases and person for table.
  4. Select SUPER for Table permissions.
  5. Choose Grant.

Grant data location permissions on the bucket to the Databricks IAM instance role.

  1. In the Lake Formation console navigation pane, choose Data Locations, and then choose Grant.
  2. For IAM users and roles, choose databricks-dataplane-instance-profile-role.
  3. For Storage locations, select the s3://icebergdemodatalake.
  4. Choose Grant.

Databricks workspace

Create a cluster and configure it to connect with a Glue Iceberg REST Catalog endpoint. For this post, we will use a Databricks cluster with runtime version 15.4 LTS (includes Apache Spark 3.5.0, Scala 2.12).

  1. In Databricks console, choose Compute in the navigation pane.
  2. Create a cluster with runtime version 15.4 LTS, access mode as ‘No isolation shared‘ and choose databricks-dataplane-instance-profile-role as instance profile role under Configuration section.
  3. Expand the Advanced options section. In the Spark section, for Spark Config include the following details:
    spark.sql.extensions org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions 
    spark.sql.catalog.spark_catalog org.apache.iceberg.spark.SparkCatalog
    spark.sql.catalog.spark_catalog.type rest 
    spark.sql.catalog.spark_catalog.uri https://glue.<aws region>.amazonaws.com/iceberg
    spark.sql.catalog.spark_catalog.warehouse <aws account number> 
    spark.sql.catalog.spark_catalog.rest.sigv4-enabled true 
    spark.sql.catalog.spark_catalog.rest.signing-name glue 
    spark.sql.defaultCatalog spark_catalog 

  4. In the Cluster section, for Libraries include the following jars:
    1. org.apache.iceberg-spark-runtime-3.5_2.12:1.6.1
    2. software.amazon.awssdk:bundle:2.29.5

Create a notebook for analyzing data managed in Data Catalog:

  1. In the workspace browser, create a new notebook and attach it to the cluster created above.
  2. Run the following commands in the notebook cell to query the data.
    #Show Databases
    df= spark.sql(“show databases”)
    display (df)



  3. Further modify the data in the S3 data lake using the AWS Glue Iceberg REST Catalog.

This shows that you can now analyze data in a Databricks cluster using an AWS Glue Iceberg REST Catalog endpoint with Lake Formation managing the data access.

Clean up

To clean up the resources used in this post and avoid possible charges:

  1. Delete the cluster created in Databricks.
  2. Delete the IAM roles created for this post.
  3. Delete the resources created in Data Catalog.
  4. Empty and then delete the S3 bucket.

Conclusion

In this post, we have showed you how to manage a dataset centrally in AWS Glue Data Catalog and make it accessible to Databricks compute using the Iceberg REST Catalog API. The solution also enables you to use Databricks to use existing access control mechanisms with Lake Formation, which is used to manage metadata access and enable underlying Amazon S3 storage access using credential vending.

Try the feature and share your feedback in the comments.


About the authors

Srividya Parthasarathy is a Senior Big Data Architect on the AWS Lake Formation team. She works with the product team and customers to build robust features and solutions for their analytical data platform. She enjoys building data mesh solutions and sharing them with the community.

Venkatavaradhan (Venkat) Viswanathan is a Global Partner Solutions Architect at Amazon Web Services. Venkat is a Technology Strategy Leader in Data, AI, ML, generative AI, and Advanced Analytics. Venkat is a Global SME for Databricks and helps AWS customers design, build, secure, and optimize Databricks workloads on AWS.

Pratik Das is a Senior Product Manager with AWS Lake Formation. He is passionate about all things data and works with customers to understand their requirements and build delightful experiences. He has a background in building data-driven solutions and machine learning systems.

Top Architecture Blog Posts of 2024

Post Syndicated from Andrea Courtright original https://aws.amazon.com/blogs/architecture/top-architecture-blog-posts-of-2024/

Well, it’s been another historic year! We’ve watched in awe as the use of real-world generative AI has changed the tech landscape, and while we at the Architecture Blog happily participated, we also made every effort to stay true to our channel’s original scope, and your readership this last year has proven that decision was the right one.

AI/ML carries itself in the top posts this year, but we’re also happy to see that foundational topics like resiliency and cost optimization are still of great interest to our audience.

(By the way, if you were hoping for more AI/ML content, head on over to our sister channel, the AWS Machine Learning Blog!).

Without further ado, here are our top posts from 2024!

#10 Deploy Stable Diffusion ComfyUI on AWS elastically and efficiently

This post helps you get started using ComfyUI, and was so successful that we followed it up later in the year with How to build custom nodes workflow with ComfyUI on EKS!

Architecture for deploying stable diffusion on ComfyUI

Figure 1. Architecture for deploying stable diffusion on ComfyUI

#9 Let’s Architect! Designing Well-Architected systems

In keeping with Let’s Architect! series, we have our first of three favorites for the year. This set of resources helps you apply Well-Architected standards in practice.

Let's Architect

Figure 2. Let’s Architect

#8 Let’s Architect! Learn About Machine Learning on AWS

As I said, Let’s Architect! has a winning series, and they’ve got a finger on the pulse of the tech world. This post about machine learning showcases some of the most exciting things happening at AWS.

Let's Architect

Figure 3. Let’s Architect

If you’re more interested in generative AI, you can also take a look at another post from 2024: Let’s Architect! GenAI

#7 Creating an organizational multi-Region failover strategy

Preparedness is another common theme in this year’s favorites. Michael, John, and Saurabh are well-versed in multi-Region architecture, and they’re here to share some strategies to contain failure impact.

When the application experiences an impairment using S3 resources in the primary Region, it fails over to use an S3 bucket in the secondary Region.

Figure 4. When the application experiences an impairment using S3 resources in the primary Region, it fails over to use an S3 bucket in the secondary Region.

#6 Building a three-tier architecture on a budget

Let’s talk cost optimization. This post about a three-tier architecture that relies on the AWS Free Tier is a must-read for anyone looking for tips to help them avoid unnecessary costs (and that’s everyone).

Example of a three-tier architecture on AWS

Figure 5. Example of a three-tier architecture on AWS

#5 Announcing updates to the AWS Well-Architected Framework guidance

As usual, Haleh & team are pros at making sure the Well-Architected Framework is current and relevant. Take a look at the enhanced and expanded guidance in all six pillars.

Well-Architected logo

Figure 6. Well-Architected logo

#4 Let’s Architect! Serverless developer experience in AWS

One more winning post from Luca, Federica, Vittorio, and Zamira! This collection of developer resources includes new ideas in AWS Lambda, Amazon Q Developer, and Amazon DynamoDB.

Let's Architect

Figure 7. Let’s Architect

#3 London Stock Exchange Group uses chaos engineering on AWS to improve resilience

This post from April 1 was not an April Fool’s joke! See how LSEG designed failure scenarios to test their resilience and observability.

Chaos engineering pattern for hybrid architecture (3-tier application)

Figure 8. Chaos engineering pattern for hybrid architecture (3-tier application)

#2 Achieving Frugal Architecture using the AWS Well-Architected Framework Guidance

Frugality AND Well-Architected? What a winning combo! This post, inspired by the 2023 re:Invent keynote, outlines the seven laws of Frugal Architecture.

Well-Architected logo

Figure 9. Well-Architected logo

#1 How an insurance company implements disaster recovery of 3-tier applications

And finally, our number one post of the year! Amit and Luiz showcase a customer solution with real-world applications that builds on the guidelines of other posts in this list! Well done!

The Pilot Light scenario for a 3-tier application that has application servers and a database deployed in two Regions

Figure 10. The Pilot Light scenario for a 3-tier application that has application servers and a database deployed in two Regions

Thank you!

As always, thanks to our contributors for their dedication and desire to share, and to you, our readers! We would be nothing with you. Literally.

For other top post lists, see our Top 10 and Top 5 posts from previous years.

California dreamin’ on such a winter’s day

Post Syndicated from original https://www.toest.bg/california-dreamin-on-such-a-winters-day/

California dreamin’ on such a winter’s day

Въпреки снежната обстановка в България през последните дни аз не мога да спра да мисля за горящия ужас, който се разрази от другата страна на света и изпепели части от Западното крайбрежие на САЩ. Ето защо този път текстът е посветен на името на най-гъстонаселения, но и изпълнения с най-много блянове американски щат – Калифорния. Заедно с Лос Анджелис и Холивуд наименованието отдавна се е превърнало не само в синоним на Америка, а и в нещо като нарицателно, обобщаващо едва ли не цялата съвременна западна цивилизация¹.

В контраст със световната популярност и разпознаваемост на наименованието Калифорния, произходът му е изненадващо слабо известен – както за хората по света, така и за самите американци, а вероятно и за повечето от близо 40-те милиона жители на самия щат. За разлика от останалите американски щати, повечето от които или са наречени на владетелите на държавите, които са ги колонизирали, или наименованията им са заимствани от езиците на местните индиански племена, произходът на „мелодичното, но величествено“ име Калифорния е доста по-любопитен.

Историческите проучвания всъщност така и не стигат до единодушно мнение по въпроса, като предлагат разнообразни теории за произхода на името, които освен изненадващи са и толкова много, че през последните 160 години са им посветени поне същият брой изследвания и анализи. (А в една от теориите, между всичко друго, дори се натъкваме и на българска връзка!)

Все пак известен консенсус – поне относно първоизточника, ако не и относно произхода на името – съществува. Редица изследователи се обединяват около теорията, че през 1533 г., когато конкистадорите на Кортес се натъкват на големия полуостров до северозападния бряг на днешно Мексико, те първоначално го вземат за остров и – в резултат на смесицата от „високи очаквания и дълбоки разочарования“ – му дават името Калифорния, което съвсем непринудено и безцеремонно заимстват от популярен тогава рицарски роман.

Въпросният роман се нарича Las sergas de Esplandián („Приключенията на Еспландиан“) и е издаден в Севиля през 1510 г. В него писателят Гарси Родригес де Монталво разказва за митичен, изобилстващ от злато остров „отдясно на Индиите“, в близост до „Земния рай“².

Островът се нарича Калифорния и се управлява от чернокожа кралица, наречена Калафия. Населен е от подобни на амазонки жени воини, които опитомяват и яздят грифони.

Кралица Калафия отвежда армията си в Константинопол, за да се сражава на страната на „езичниците“, но в края на краищата бива победена и приема християнството.

Тази история е поредното доказателство, че освен завоеватели, конкистадорите се оказват и изключително находчиви именодатели, макар че прибягват до доста произволни названия (виж историята с пуйката). С придвижването им на север и навътре в сушата, наименованието Калифорния се разширява отвъд полуострова, станал известен като Baja California („Долна Калифорния“), за да обхване и териториите на днешните американски щати Калифорния, Невада и Юта, както и части от Аризона, Уайоминг и Колорадо, които пък получават названието Alta California („Горна Калифорния“) или Nueva California („Нова Калифорния“). Цялата територия, носеща общото име Las Californias, съществува като провинция на Испанската империя в периода 1767–1804 г.

Произходът на наименованието Калифорния и връзката му с книгата обаче са „открити“ едва през 1862 г. – 12 години след като Калифорния става 31-вия американски щат (неговото мото и до днес е „Еврика“!), – когато американският писател, историк и свещеник Едуард Еверет Хейл ги посочва в свое изследване. Впоследствие други историци потвърждават теорията като много вероятна и на свой ред правят редица предположения за това как наименованието се е оказало в романа на Монталво и дали то е неологизъм, заемка или преиначена версия на вече съществуваща дума.

През 1917 г., авторката и суфражетка Рут Пътнам публикува изключително подробно, изненадващо забавно и изпълнено с духовити наблюдения проучване от стотина страници със заглавие California: the Name. Там тя посочва Las sergas de Esplandián като вероятен първоизточник на думата и предлага своя допълнителна интерпретация. Според нея името Калафия (и съответно наименованието Калифорния) произлиза от срещаната в много европейски езици дума caliph (навлязла в българския като „халиф“) – титла, означаваща „владетел“ или „водач“, заимствана от арабската خَلِيف (ḵalīf), или „наследник“, но преобразувана в женски род³. Пътнам аргументира това свое твърдение с реторичния въпрос: „Какво по-естествено наименование за суверенна кралица, съюзник на турските езичници?“

Заедно с това Пътнам разглежда и редица други теории за етимологията на наименованието, които в края на краищата отписва като неблагонадеждни, но това не ги прави по-малко любопитни.

Според една от теориите – базирана на твърденията на Монталво, че се е сдобил с разказа от книгата посредством някакъв грък – писателят си е измислил наименованията на базата на гръцки корени: Calafia – от καλλι- (kăllí), коeто в комбинация с други думи означава „красив“, и φίλη (phile), тоест „приятелка“, или пък от καλλιφυής (kalliphues) – „красиво израснал“ или „добре развит“; California – от καλλι- и ὄρνις (ornis), тоест „птица“, като това е подкрепено от твърдението в книгата, че на острова живеят много грифони, които не се срещат в друга част на света.

Когато Пътнам се консултира с различни специалисти по старогръцки обаче, те обявяват тази теория за несъстоятелна, отбелязвайки, че що се отнася до формирането на фантастичните наименования в така наречените libros de caballerías от XVI век, всякакви опити за научен подход са безполезни. Вместо това специалистите предполагат, че наименованията са резултат от асоциативно мислене, подобно на детското, което си играе със звуците на вече съществуващи чудновати думи.

Други източници отбелязват, че е възможно Монталво да е заимствал името Калифорния от съществуващи географски наименования, например Californo и Calafornina в Сицилия или Calahorra в Испания.

В трета версия се посочва предполагаема връзка на името Калифорния с персийското понятие kar-i-farn, обозначаващо митологична „райска планина“, където живеят грифони⁴.

Според четвърта теория наименованието произхожда от латинското словосъчетание calida fornax, или „гореща пещ“, преминало в староиспанския като calit fornay, с което завоевателите на Кортес са оприличили климата на тази част на света при първия си сблъсък с нея. Отбелязвайки, че „нашите conquistadores“ не са били особено начетени, а и не са имали навика да измислят имена на завоеванията си по този начин, Пътнам оборва поредната версия.

Същата съдба сполетява и предположението, че наименованието Калифорния се корени в езиците на местното население, на които kali forno означава „високи хълмове“ или „високи планини“, а думата за „полуостров“ – tchali-falni-al, означава „пясъчната земя отвъд водата“.

В самия край на изследването си Пътнам споменава и версията, че названието идва от Калпурния – името на третата жена на Юлий Цезар, но предположението явно е толкова неблагонадеждно, че авторката дори не го удостоява с допълнителни обяснения.

Сред всички тези много или малко (не)вероятни теории обаче Пътнам откроява и една доста по-убедителна според нея хипотеза, която „прехвърля отговорността за измислянето на името от раменете на Монталво към неизвестния автор“ на старофренския епос La Chanson de Roland от XI век. В стих CCIX от епоса Карл Велики оплаква смъртта на племенника си Роланд и изрежда враговете, които ще го нападнат веднага щом разберат за кончината на храбрия войн. В оригиналния старофренски вариант това изреждане гласи:

Morz est mis nies, ki tant me fist cunquere
Encuntre mei revelerunt li Seisne,
E Hungre e Bugre e tante gent averse,
Romain, Puillain et tuit icil de Palerne
E cil d'Affrike e cil de Califerne;

И без да знаем старофренски, ясно можем да видим, че Affrike и Califerne са сред местата, откъдето се очакват вражески нападения. Това, което може обаче да ни е убегне, е, че списъкът с потенциални варварски агресори, освен саксонци и унгарци, римляни, пулианци (от Пулия) и нашественици от Палермо, също така включва и българи! Виждаме го съвсем ясно в превода на „Песен за Роланд“ от Лъчезар Станчев от старофренски, издаден през 1985 г.:

Умря Роланд, завзел ми не една страна.
Саксонци, хунгри, българи без страх
ще дойдат с рой враждебни племена,
и Рим, Палермо, Пулия със тях,
и тез от Африка и Калиферне чак!

В своето изследване Пътнам отбелязва, че повечето преводи и издания на епоса включват наименованието Califerne без никакъв коментар, някои го маркират като неясно или в най-добрия случай го обясняват като някакво въображаемо халифско владение. В бележка към превода си Лъчезар Станчев пък твърди, че „Калиферне е вероятно местност в Азия“.

Станчев, изглежда, е пропуснал издаденото през 1923 г. проучване на френския историк Проспер Буасонад, резюмирано тук от американския историк Хърбърт Д. Остин, което доста убедително разсейва мистерията около значението, произхода и етимологията на наименованието Калиферне, споменато в „Песен за Роланд“. Според Буасонад то е заимствано от крепостен град на територията на днешен Алжир, който през XI век, благодарение на богатството и великолепието си, е бил обект на страх и почитание сред европейските християни. Името на града – Kalaa-Ifrene или Kal-Ifrene – произлиза от арабската дума قلعة (qalea, тоест „крепост“, навлязла и в българския като „кале“), с която тогава са се обозначавали този вид крепостни градове, в комбинация с името на берберското племе бени ифрен, което го обитавало.

Стъпвайки на проучването на Буасонад, аз пък откривам доста интересна теория за етимологията на наименованието Ифрен. Според арабския учен и философ Ибн Халдун племето е наследило името от своя предшественик Ифри, което на берберските езици (ⵉⴼⵔⵉ) означава „пещера“. Други изследователи отбелязват, че Ифри е името на берберска богиня на слънцето, на пещерите и пазителка на дома, почитана преди приемането на исляма от берберите. (Ето как се оказва, че макар и първоначалната теория за арабския произход на наименованието Калифорния от „халиф“ да не уцелва езика и религията, все пак е налучкала приблизителния географски произход на първоизточника.)

Така или иначе, някогашният великолепен берберския град замира и изчезва през XII век, около столетие след появата му в „Песен на Роланд“. Но благодарение на споменаването му в старофренския епос, а впоследствие и на ненадейното му достигане (с известни изменения и посредством испанския рицарски роман) до западния бряг на новооткритата Америка четири века след това, името Калифорния не само оцелява, а пет века по-късно се превръща в едно от най-известните и разпознаваеми географски наименования в наши дни.

Невъзможно е да предвидим как – и дали изобщо – то ще премине през вековете напред. Дали след 900 години името Лос Анджелис, подобно на Кал-Иферн (и също като него идващо от свещена женска фигура), няма да съществува само в историческите архиви като обозначение на някога процъфтяващ град, впоследствие унищожен от пожари, земетресения, урагани, цунами и други природни, но предизвикани от хората потопи⁵? Няма как да знаем. Можем само да се надяваме в краткосрочен план, че Лос Анджелис и Калифорния ще се възстановят и от сегашното бедствие, а в по-дългосрочен – че с времето наименованията им няма да останат свързани само със спомени за отминали мечти, слава, блясък и богатства, а ще продължат да обозначават места, където животът продължава да процъфтява.

1 В сравнение с изключително оплетените и разнопосочни версии за произхода и етимологията на Калифорния, произходът на името Лос Анджелис е ясно установен и относително прост, макар и не толкова широко познат. Повечето хора знаят, че съкращението Ел Ей означава Лос Анджелис, а сигурно част от тях са запознати и с прозвищата, с които е известен градът – сред тях са La-La Land, City of Angels, The Big Orange и Tinseltown. Но вероятно малцина знаят, че пълното оригинално име на града, дадено му от испанците през 1781 г., e El Pueblo de Nuestra Señora la Reina de los Ángeles del Río Porciúncula, или „Градът на Дева Мария, царица на ангелите, на река Порсюнкула“. Оказва се, че Лос Анджелис притежава както едно от най-кратките, така и едно от най-дългите географски имена на света.

2 Най-старото оцеляло издание на Las sergas de Esplandián е публикувано в Севиля през 1510 г. Смята се, че по-ранни издания са били публикувани още през 1496 г., като Рут Пътнам твърди, че Монталво е завършил романа си някъде след 1492 г. Книгата на Монталво се споменава в публикувания през 1605 г. „Дон Кихот де ла Манча“ на Мигел де Сервантес – там тя е първата книга от библиотеката на благородника, която близките му решават да запратят на кладата, смятайки я за източник на ексцентричното му поведение.

3 Твърдението, че името на кралица Калафия и остров Калифорния в испанския рицарски роман произлизат от арабската дума خَلِيف (ḵalīf), се основава на факта, че във втората половина на XV и началото на XVI век, тоест в периода непосредствено около и след издаването на Las sergas de Esplandián, Испания все още е под силно арабско влияние. Езикови следи от това влияние са налице и до днес: според Испанската кралска академия от общо 93 000 думи, които съществуват в кастилския език днес, около 4000 са с арабски произход.

4 Името на Калифорния може и да не произлиза от персийската дума за „райска планина“, където живеят грифони, но за сметка на това едно от прозвищата на лосанджелиския квартал „Уестуд“ е Tehrangeles (от „Техеран“ + „Лос Анджелис“) – заради голямата иранска общност (наброяваща между 500 000 и 600 000 души), сформирана от иранските имигранти, които се заселват в града след Ислямската революция в Иран през 1979 г., и техните потомци. Според иранско-американския учен Реза Аслан афинитетът на иранците към Лос Анджелис отчасти може да бъде обяснен с това, че много аспекти от града – пейзажът, културата на придвижване с кола, планините – им напомня за Иран през 70-те.

5 Няма как този текст да завърши, без да споменем и наименованието на пагубния природен феномен, смятан за главния причинител на пожарите в Лос Анджелис – ветровете „Санта Ана“. Техният произход навътре в сушата може и да не е оспорван, но произходът на наименованието им е обект на известни спекулации. Според най-често срещаното и широко прието обяснение ветровете са наречени на каньон на юг от Лос Анджелис със същото име, през който ветровете минават, преди да достигнат града, а алтернативното прозвище на „дяволските ветрове“ – Santana, е просто скъсена в разговорния език версия на „Санта Ана“. Според друга интересна теория, за която обаче няма достатъчно доказателства, развитието на алтернативното наименование е протекло в обратна посока, тоест произлиза от индианската дума santana, означаващa „голям вятър“, „дяволски вятър“ или „вятър на лошите духове“, която испанците първоначално преиначили на Satanás („Сатана“), а впоследствие се е трансформирала в Santa Ana. Етимологията, както и природните бедствия понякога наистина са дяволска работа.

 В рубриката „От дума на дума“ Екатерина Петрова търси актуални, интересни или новопоявили се думи от нашето ежедневие и проследява често изненадващия им произход, развитието на значенията им във времето и взаимовръзките им с близки и далечни езици.

Addressing the digital skills gap

Post Syndicated from Rachel Arthur original https://www.raspberrypi.org/blog/addressing-the-digital-skills-gap/

The digital skills gap is one of the biggest challenges for today’s workforce. It’s a growing concern for educators, employers, and anyone passionate about helping young people succeed.

Digital literacy is essential in today’s world, whether or not you’re aiming for a tech career — yet too many young people are entering adulthood without the skills to navigate it confidently and recent research shows that many young people finish school without formal digital qualifications.

Whilst this challenge is a global one, we’re exploring solutions in England where computing has been part of the national curriculum for a decade and the option of studying for a qualification (GCSE) in computer science is available to many 14-year-olds.

The SCARI report shows that GCSE computer science isn’t available in every school in England, and even where it is available, only a fraction of students opt to study it. Where GCSE computer science is offered, the focus is not on broader digital skills, but more on programming and theoretical knowledge which, while important, doesn’t support young people with the knowledge they need to succeed in the modern workplace.

How the Manchester Baccalaureate will help tackle the digital divide

At the Raspberry Pi Foundation, we’re working with the Greater Manchester Combined Authority to tackle this challenge head-on. Together, as part of their Manchester Baccalaureate initiative, we’re developing a self-paced course and certification to tackle the digital skills gap directly. 

Teachers listening to a presentation at a recent workshop the Raspberry Pi Foundation held in Manchester.

The Raspberry Pi Foundation Certificate in Applied Computing is designed to be accessed by any pupil, anywhere. It includes a series of flexible modules that students can work through at their own pace. Targeted at young people ages 14 and up, the certificate covers three stages:

  • Stage 1 – Students gain essential digital skills, preparing them for a wide range of careers
  • Stages 2 and 3 – Students dive into specialisations in key tech areas, building expertise aligned with in-demand roles

What we’ve learnt in Manchester so far

We recently visited Oasis Academy Media City to hold a workshop on digital skills and get input on the certificate. We welcomed educators and industry experts to share their insights, and their feedback has been invaluable.

Teachers pointed out a common challenge: while they see the importance of digital skills, they often lack the time and resources to add new material to an already packed curriculum. By offering the certification as bite-sized modules that focus on specific skills, it makes it easier to slot the content into the timetable, and helps students with limited access to school (due to illness, for example) engage with the course.

Teachers listening to a presentation at a recent workshop the Raspberry Pi Foundation held in Manchester.

Educators were particularly excited about the opportunity for students to specialise in areas tied to in-demand roles that are currently being recruited for and our goal is to make the qualification engaging and relevant, helping students see how their learning applies in the real world.  

Next steps

We are currently piloting this qualification in schools throughout Manchester, gathering invaluable feedback from young people as they embark on this learning experience, which will help us refine the course.
Our full qualification will launch later this year, and we can’t wait to help students approach their futures with curiosity and confidence.

The post Addressing the digital skills gap appeared first on Raspberry Pi Foundation.

The first part of the 6.14 merge window

Post Syndicated from corbet original https://lwn.net/Articles/1005651/

As of this writing, just over 4,300 non-merge changesets have been pulled
into the mainline repository for the 6.14 release. Many of the pull
requests this time around include remarks saying that activity has been
relatively low this time around, presumably due to the holidays. So those
4,300 changesets are probably closer to the merge-window halfway point than
usual. Much of the work merged thus far looks more like incremental
improvements than major new initiatives, but there still have been a number
of interesting changes in the mix.

Security updates for Thursday

Post Syndicated from jake original https://lwn.net/Articles/1005946/

Security updates have been issued by AlmaLinux (redis:6), Debian (frr and git-lfs), Fedora (SDL2_sound and webkit2gtk4.0), Gentoo (firefox, GPL Ghostscript, libgsf, libuv, PHP, Qt, QtWebEngine, and Yubico pam-u2f), Mageia (chromium-browser-stable), SUSE (helmfile, nvidia-modprobe, qt6-webengine, ruby3.4-rubygem-actioncable-8.0-8.0.1-1.1, ruby3.4-rubygem-actionpack-8.0-8.0.1-1.1, ruby3.4-rubygem-actiontext-8.0-8.0.1-1.1, ruby3.4-rubygem-actionview-8.0-8.0.1-1.1, ruby3.4-rubygem-activejob-8.0-8.0.1-1.1, ruby3.4-rubygem-activerecord-8.0-8.0.1-1.1, ruby3.4-rubygem-activestorage-8.0-8.0.1-1.1, ruby3.4-rubygem-rails-8.0-8.0.1-1.1, and ruby3.4-rubygem-railties-8.0-8.0.1-1.1), and Ubuntu (bluez, openjpeg2, and python-django).

Third Interdisciplinary Workshop on Reimagining Democracy (IWORD 2024)

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/01/third-interdisciplinary-workshop-on-reimagining-democracy-iword-2024.html

Last month, Henry Farrell and I convened the Third Interdisciplinary Workshop on Reimagining Democracy (IWORD 2024) at Johns Hopkins University’s Bloomberg Center in Washington DC. This is a small, invitational workshop on the future of democracy. As with the previous two workshops, the goal was to bring together a diverse set of political scientists, law professors, philosophers, AI researchers and other industry practitioners, political activists, and creative types (including science fiction writers) to discuss how democracy might be reimagined in the current century.

The goal of the workshop is to think very broadly. Modern democracy was invented in the mid-eighteenth century, using mid-eighteenth-century technology. If democracy were to be invented today, it would look very different. Elections would look different. The balance between representation and direct democracy would look different. Adjudication and enforcement would look different. Everything would look different, because our conceptions of fairness, justice, equality, and rights are different, and we have much more powerful technology to bring to bear on the problems. Also, we could start from scratch without having to worry about evolving our current democracy into this imagined future system.

We can’t do that, of course, but it’s still still valuable to speculate. Of course we need to figure out how to reform our current systems, but we shouldn’t limit our thinking to incremental steps. We also need to think about discontinuous changes as well. I wrote about the philosophy more in this essay about IWORD 2022.

IWORD 2024 was easily the most intellectually stimulating two days of my year. It’s also intellectually exhausting; the speed and intensity of ideas is almost too much. I wrote the format in my blog post on IWORD 2023.

Summaries of all the IWORD 2024 talks are in the first set of comments below. And here are links to the previous IWORDs:

IWORD 2025 will be held either in New York or New Haven; still to be determined.

Key Takeaways: Mastering Risk Prioritization with Rapid7 Surface Command

Post Syndicated from Emma Burdett original https://blog.rapid7.com/2025/01/23/key-takeaways-mastering-risk-prioritization-with-rapid7-surface-command/

Key Takeaways: Mastering Risk Prioritization with Rapid7 Surface Command

Managing risk in today’s sprawling IT environments demands precision and adaptability. Security teams face a constant influx of data from various tools, each offering fragmented insights. Rapid7’s Surface Command takes control of this chaos, consolidating data and delivering actionable insights through custom risk management strategies.

In our recent webinar, Chaney Edwards, Senior Security Solutions Engineer at Rapid7, shares actionable techniques to cut through noise, prioritize effectively, and command your attack surface. Here’s what you’ll gain.

Key Takeaways from the Webinar

1. Start with Tailored Risk Scoring
Effective risk prioritization starts with understanding what matters most to your business. During the webinar, Edwards highlights strategies to move away from generic scoring systems, such as identifying which tools provide the most accurate data for specific asset types and aligning risk scores with your operational priorities.

2. Bridge Data Silos for a Clearer View
A key takeaway from the webinar is the importance of integrating data from across your environment. Teams often lose valuable time reconciling conflicting metrics from different tools. Edwards discusses the advantages of using a unified framework to correlate insights from multiple sources, ensuring consistent decision-making.

3. Use Queries to Uncover Insights Quickly
Advanced queries don’t just save time; they also uncover patterns you might otherwise miss. Edwards demonstrates how to build queries that reveal key risks, such as identifying assets with outdated configurations, unpatched vulnerabilities, or public-facing endpoints.

Why Watch the Webinar?

This webinar offers more than a product overview—it’s packed with actionable advice for improving your risk management strategy. Whether it’s learning to build custom risk scores, integrating data sources, or designing better queries, you’ll come away with tools and strategies to elevate your approach to risk prioritization.

Watch the webinar here.

Monitoring Sensor Data with Zabbix and Modbus Protocol

Post Syndicated from Nyein Chan Zaw original https://blog.zabbix.com/monitoring-sensor-data-with-zabbix-and-modbus-protocol/29471/

This week’s blog entry comes to us from Nyein Chan Zaw, who is based in Bangkok, Thailand and works as an Infrastructure Specialist for Green Will Solution. Read on to see how he uses his integrating a Modbus protocol with Zabbix to monitor data from temperature, humidity, and smoke sensors — and display their metrics on a Zabbix dashboard.

Step 1: Collecting Sensor Data via Modbus Protocol

This snapshot shows how all three sensors are synchronized with the Modbus protocol, confirming that the communication is operational.

In the initial setup, the temperature, humidity, and smoke sensors transmit their data to the Modbus protocol. This data synchronization can be visualized using Modbus polling software, where the values from each sensor are displayed in real-time.

Step 2: Configuring Modbus Files on Zabbix Agent

This snapshot demonstrates the configuration of three MB files corresponding to the three sensors.

To enable Zabbix to communicate with Modbus, the Modbus configuration (MB) files must be set up in the Zabbix Agent configuration file on the Zabbix server. Each sensor requires an individual MB configuration entry, specifying the Modbus parameters such as function code, register address, and data type.

Step 3: Creating a Host for Modbus Protocol in Zabbix

Next, a Zabbix host must be created to represent the Modbus protocol device.

This snapshot highlights the host creation process with the associated IP address and configuration details.

During this process, assign the Modbus protocol’s IP address as the host’s interface. Configure the interface to communicate with the Zabbix server using the Zabbix agent.

Step 4: Configuring Items for Each Sensor

Each sensor requires an item in Zabbix to capture its data.

This snapshot shows how items are configured for each sensor.

For every item, specify the Name for identification (e.g., Temperature Sensor). Define the Key, which includes the Modbus protocol function and register settings, to ensure accurate data retrieval.

Step 5: Viewing and Utilizing Sensor Data in Zabbix

This snapshot displays the Zabbix dashboard, showcasing data from all three sensors.

Once the host and items are configured, Zabbix starts collecting data from the Modbus protocol. This data is displayed in the Zabbix interface, where metrics for temperature, humidity, and smoke are updated in real-time. Additionally, a custom dashboard can be created to visualize all three sensors’ data at a glance, providing actionable insights for monitoring and decision-making.

Conclusion

Integrating Modbus with Zabbix streamlines the monitoring of sensor data, making it easy to collect, visualize, and act upon critical metrics. This process demonstrates Zabbix’s flexibility and scalability in managing industrial protocols and data sources, ensuring robust monitoring for diverse applications.

If you’re looking to implement similar solutions or need help integrating Modbus with Zabbix, feel free to reach out in the comments below!

The post Monitoring Sensor Data with Zabbix and Modbus Protocol appeared first on Zabbix Blog.

The collective thoughts of the interwebz