> ## Documentation Index > Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt > Use this file to discover all available pages before exploring further. # Terminologia No AppSignal, usamos muitos termos técnicos. Continue lendo para aprender mais sobre a linguagem do AppSignal. Veja a lista de terminologia no lado direito desta página. ## Actions As actions são o local no código onde uma requisição HTTP, job em background, cron job ou tarefa é iniciada. Para apps Ruby on Rails e Phoenix do Elixir, essa é a combinação de controller e action, como `BlogPostsController#create` ou `Api::UsersController#index`. Para jobs em background, esse será o nome do worker/job, como `UserMailer#sign_up_mail`. As actions são usadas para agrupar [issues](#issues) junto com o [namespace](#namespace) e o [error](#errors). ## Agente O AppSignal usa um "agente" para se comunicar com os servidores do AppSignal e instrumentar os hosts em que uma aplicação está sendo executada. Os dados do host são usados em nosso recurso de [métricas de host](/metrics/host-metrics). O agente é iniciado pela [biblioteca](#libraries) específica da linguagem e roda como um processo UNIX separado no host da aplicação. A biblioteca de linguagem e o agente se comunicam por meio de um socket UNIX usando uma [extensão](#extension). Os dados de instrumentação de transações coletados pelo agente são enviados aos servidores do AppSignal. Os dados de [transações](#transactions) são processados e usados para detectar eventos que valem a pena alertar os usuários. Leia mais sobre como o [agente do AppSignal opera](/appsignal/how-appsignal-operates) e o [ciclo de vida de uma requisição do AppSignal](/appsignal/data-life-cycle). ## Allocations Durante uma requisição HTTP ou um job em background, uma aplicação usa memória. Cada estrutura de dados que é carregada e objeto que é instanciado ocupa memória. Quando uma requisição ou job lida com muitos dados, muito mais memória pode ser usada do que o normal. As bibliotecas de integração do AppSignal mantêm o controle de alocações por [transação](#transactions). A integração também mantém o controle de qual parte da aplicação aloca mais objetos de memória do que outras, então é possível ver se o ORM ou a biblioteca de templates da aplicação está consumindo mais memória. No AppSignal.com, o número de alocações é exibido em um Integer para uma action, grupos de eventos e eventos específicos. Esse número de alocação é o número de objetos que foram criados em memória durante uma action/grupo/evento. O tamanho do objeto criado não é rastreado. ## Detecção de anomalias A detecção de anomalias é um recurso do AppSignal que permite aos usuários detectar anormalidades em seus apps. Uma anomalia pode ser algo como uma taxa de erro aumentada ou uma quantidade limitada de memória livre no host do app. A detecção de anomalias funciona com condições de limite de trigger que criam Alertas quando seu limite é atingido. Quando um Alerta é aberto, o AppSignal enviará notificações para quaisquer notificadores que foram selecionados para o trigger específico. Veja nossa documentação sobre [Detecção de anomalias](/anomaly-detection/) para mais informações. ## API API é uma "Application Programming Interface". O termo API é amplo e é usado de muitas formas. No contexto da nossa documentação, nos referimos à API HTTP REST do AppSignal ao usar "API". A API do AppSignal é uma API HTTP REST que pode ser usada para recuperar dados dos servidores do AppSignal e enriquecer os dados existentes com mais informações, como [Markers](#markers). A API difere da [Push API](#push-api) em seu propósito. Enquanto a Push API é usada para enviar dados ao AppSignal pelo [agente](#agent), a API HTTP REST é usada principalmente para recuperar dados do AppSignal. Isso permite que os usuários usem os dados disponíveis em outras ferramentas. Você pode ler mais sobre nossa API em nossa [documentação da API](/api). ## API key Para se conectar com a [API](#api) do AppSignal, é necessário estar autenticado. Cada usuário tem sua API key para se autenticar com o AppSignal. Sua API key pode ser encontrada no seu [perfil de usuário](https://appsignal.com/users/edit). Essa chave não deve ser confundida com a [Push API key](#push-api-key), que é usada por [aplicações](#applications) com um [agente](#agent) do AppSignal instalado. ## Applications Aplicações (anteriormente conhecidas como "sites", também referidas como "apps") são aplicações Ruby e Elixir monitoradas pelo AppSignal. Após instalar a [biblioteca](#libraries) do AppSignal em uma aplicação, o AppSignal começa a monitorar essas aplicações. Uma vez que recebemos dados de uma aplicação, nós a registramos usando o nome da aplicação e o ambiente em que está sendo executada. Uma aplicação pode ter múltiplos [ambientes](#environments) desde que cada ambiente use o mesmo nome. * "Demo application" - Development * "Demo application" - Production * "Demo application" - Staging * "Demo application" - Test Múltiplas aplicações podem existir em uma [organização](#organizations). Leia mais sobre aplicações em nossa [documentação de Aplicações](/application). ## AppSignal vs Appsignal vs appsignal Espera, são *três* grafias diferentes do nome AppSignal? Sim! Vamos explicar: | Grafia | Uso | | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `AppSignal` | O nome da marca da empresa, da aplicação e de quase tudo mais relacionado ao AppSignal. Esta é a versão que você deve usar ao falar sobre o AppSignal como marca, produto ou serviço ou [fornecedor de stroopwafels](#stroopwafels). | | `Appsignal` | O nome da biblioteca das nossas integrações AppSignal ([integração Ruby](/ruby), [integração Elixir](/elixir), [integração Node.js](/nodejs/3.x/), [integração Front-end](/front-end) etc.). Usado apenas no contexto de código. | | `appsignal` | Os nomes de pacote das integrações AppSignal conforme publicados nos registros de gerenciadores de pacotes para a [gem Ruby](https://rubygems.org/gems/appsignal), [pacote Elixir e prefixo de pacotes](https://hex.pm/packages/appsignal), [prefixo de pacotes Node.js](https://www.npmjs.com/package/@appsignal/nodejs) e [prefixo de pacotes Front-end](https://www.npmjs.com/package/@appsignal/javascript), etc. | ## Blog Nós temos um blog em [blog.appsignal.com](https://blog.appsignal.com/)! Em nosso blog, postamos coisas relevantes para o AppSignal, como novos recursos, lançamentos de agentes principais, artigos [Ruby Magic](#ruby-magic) e outras histórias incríveis do nosso processo interno. Como [como comer stroopwafels](https://blog.appsignal.com/blog/2016/02/01/stroopwafels-and-how-to-eat-them.html). ## Changelog Mantemos um changelog completo do produto em [appsignal.com/changelog](https://www.appsignal.com/changelog). Todos os nossos novos recursos, lançamentos de agentes e outras mudanças no produto podem ser encontradas nessa lista organizada. Também temos um pequeno indicador na nossa navegação superior que notifica você se há uma nova entrada no changelog. ## Configuração A configuração é parte das bibliotecas em execução nas aplicações. Ela diz às [bibliotecas](#libraries) do AppSignal o que instrumentar em uma [aplicação](#applications), qual aplicação ela é e em qual ambiente está sendo executada. As bibliotecas do AppSignal têm múltiplos métodos de configuração. O método mais comum de configuração é o uso de um arquivo de configuração `appsignal.yml`. O uso de variáveis de ambiente também é recomendado. Para a configuração do agente Ruby, recomendamos que você leia o [tópico de configuração](/ruby/configuration) para começar. ## Uso de CPU Durante a operação de uma aplicação, o uso de CPU pode variar muito. Algumas operações de uma aplicação podem solicitar mais tempo de CPU do que outras. Outros fatores também podem afetar o uso de CPU. Se a aplicação monitorada não for o único processo na máquina host, outros processos também podem afetar a métrica de uso de CPU. Por exemplo, se um banco de dados em execução na mesma máquina precisar executar uma consulta complicada, ele solicitará mais tempo de CPU. No AppSignal.com, o uso de CPU de uma aplicação é exibido de duas maneiras. Para uma action onde ocorreu um erro/problema de desempenho e para métricas de host. Dessa forma, é possível ver se o desempenho de uma action foi diretamente afetado por uma CPU ocupada ou se o host inteiro foi afetado por períodos mais longos. Saiba mais sobre o que [métricas de CPU](https://blog.appsignal.com/2018/03/06/understanding-cpu-statistics.html) significam em nosso blog. ## Cross-Site Request Forgery Cross-Site Request Forgery (CSRF) é um ataque que força um usuário final a executar ações indesejadas em uma aplicação web onde está autenticado. Uma vítima pode clicar em um link enviado por e-mail ou chat na web, permitindo que o atacante roube e use as credenciais da vítima. A gravidade do ataque pode variar dependendo da aplicação e do acesso de autorização da conta da vítima. Um atacante pode ser capaz de fazer ações que alteram o estado de uma conta de usuário, como alterar suas credenciais de login, e pode comprometer uma aplicação inteira em casos graves, como quando uma vítima é um administrador. ## Elixir Alchemy Quer aprender mais sobre Elixir? Em nossa série de e-mails Elixir Alchemy (1x por mês), mergulhamos mais fundo em Elixir e Erlang. Você pode se inscrever aqui: [appsignal.com/elixir-alchemy](https://blog.appsignal.com/elixir-alchemy). ## Ambientes A maioria das [aplicações](#applications) pode ser executada em modos diferentes. Durante o desenvolvimento de uma aplicação, outras regras se aplicam e os erros geralmente não são mostrados na forma de uma página de "500 internal server error", como acontece em "production". O AppSignal também entende o conceito de um ambiente, permitindo que diferentes configurações sejam configuradas por ambiente. Para cada ambiente, uma aplicação separada é criada no AppSignal.com para ser configurada com seu próprio conjunto de regras de alerta e [integrações de terceiros](#third-party-integrations). ## Erros Erros são problemas que ocorrem durante a execução de uma aplicação. Isso pode ser qualquer coisa, desde uma falha catastrófica que faz com que a aplicação trave até um simples erro de digitação que causa uma página de erro. Uma vez que um erro ocorre em uma aplicação, o AppSignal envia um alerta e registra os detalhes do erro para visualização posterior no AppSignal.com. Leia mais sobre o [recurso de erros](https://www.appsignal.com/tour/errors) em nossa página de tour. Para saber mais sobre o tratamento de erros em Ruby, leia nosso tópico de [Tratamento de exceções](/ruby/instrumentation/exception-handling) descrevendo como rastrear erros efetivamente com o AppSignal. Erros são reportados como issues. Saiba mais sobre o que são [issues](#issues). ## Eventos Um evento é algo que aconteceu. Esta é uma declaração muito vaga porque o conceito de um evento é algo muito de alto nível. Um [erro](#errors) é um evento, e um [problema de desempenho](#performance-issues) também. O AppSignal monitora muitos eventos dentro de uma aplicação e em um servidor usando [métricas de host](#metrics). Coletando muitos tipos diferentes de eventos e combinando os dados, esperamos fornecer uma imagem o mais completa possível para obter mais insights sobre o desempenho das [aplicações](#applications). Veja também a [documentação de eventos de instrumentação](#instrumentation-events). ## Extensão As [bibliotecas](#libraries) e o [agente](#agent) do AppSignal estão em constante comunicação um com o outro. As bibliotecas enviam dados ao agente por meio de um socket UNIX. Para fazer isso, as bibliotecas usam uma extensão para a linguagem de programação em que estão escritas. Essa extensão é escrita em C e Rust, e é instalada quando o agente específico da linguagem é instalado. Leia mais sobre como a [extensão do AppSignal opera](/appsignal/how-appsignal-operates) e o [ciclo de vida de uma requisição do AppSignal](/appsignal/data-life-cycle). ## Impacto O impacto de uma action em uma aplicação é baseado em seu uso em comparação com outras actions. Quando uma action de controller ou job leva mais tempo ou é executada mais frequentemente do que outras, seu impacto cresce. Por exemplo: * A Action A é acionada 1000 vezes com uma duração média de 0,5 segundos. A duração combinada é de 500 segundos. * A Action B é acionada 500 vezes com uma duração média de 3 segundos. A duração combinada é de 1500 segundos. A duração combinada total de ambas as actions é de 2000 segundos. * A Action A tem um impacto de 25% (500 / 2000). * A Action B tem um impacto de 75% (1500 / 2000). ## Instrumentação A instrumentação é o que dá poder ao AppSignal. Sem ela, não saberíamos nada sobre o que está acontecendo dentro das aplicações. Instrumentação são hooks dentro ou ao redor de frameworks e bibliotecas que o AppSignal usa para monitorar o código da aplicação. Essa instrumentação reporta erros e código lento que é enviado ao AppSignal para análise. Uma vez que um problema é detectado, um alerta é enviado. Saiba mais sobre [instrumentação Ruby](/ruby/instrumentation). ## Eventos de instrumentação Eventos são blocos de código que são executados. Podem ser métodos, funções ou partes menores deles. Eventos podem ser aninhados para mostrar hierarquia e a duração total das operações. Esses eventos individuais tornam possível ver quais partes do código são mais lentas do que outras. No topo das [páginas de issues](#issues), também agrupamos as durações de eventos por nome de grupo, seguindo a [nossa nomenclatura de eventos](/api/event-names), para fornecer insights sobre qual parte do app demora mais. Alguns tipos de eventos que podem ser mostrados são consultas de banco de dados, parsing de JSON, renderização de views, requisições HTTP, [instrumentação personalizada](#instrumentation), etc. Cada evento é mostrado nas páginas de detalhes de problemas de desempenho na "linha do tempo de desempenho". Se detectarmos que o mesmo evento é repetido mais de uma vez em sucessão, vamos marcá-los como potenciais eventos N+1, como consultas N+1. Veja também [instrumentação](#instrumentation). ## Issues Sempre que o AppSignal detecta um novo erro, uma issue é criada. Sempre que o AppSignal detecta uma nova potencial requisição lenta, job em background, etc. uma nova issue é criada. Essa issue é agrupada por [action](#actions), [namespace](#namespace) e [error](#errors). Issues de erro também suportam erros sem action, pois um erro pode ocorrer fora de uma action, como no framework do app antes de chegar ao código do próprio app. Problemas de desempenho sem uma [action](#actions) são silenciosamente ignorados. A action, o [namespace](#namespace) e o tipo de erro são a forma como agrupamos issues. Se um erro de um novo tipo ocorre na mesma action no mesmo namespace que outra issue de erro, uma nova issue será criada para esse erro. Se outra potencial requisição lenta é detectada em outro endpoint ou job em background, uma nova issue será criada para esse endpoint/job. Por issue, é possível configurar configurações de notificação, atribuição, estado (aberto/fechado/em andamento) e severidade. ## Bibliotecas O AppSignal usa bibliotecas específicas de linguagem para monitorar aplicações. Atualmente, temos uma gem [Ruby](/ruby) e um pacote [Elixir](/elixir). Essas bibliotecas incluem hooks em frameworks e bibliotecas para instrumentar blocos de código, como chamadas de banco de dados, chamadas de sistema de arquivos e renderização de views. Cada biblioteca é especializada na instrumentação da linguagem de sua especialidade. A maioria das bibliotecas do AppSignal também inclui um "[agente](#agent)" que as bibliotecas usam para se comunicar com os servidores do AppSignal. Leia mais sobre como o [agente do AppSignal opera](/appsignal/how-appsignal-operates) e o [ciclo de vida de uma requisição do AppSignal](/appsignal/data-life-cycle). ### Integrações de bibliotecas As bibliotecas do AppSignal se integram com uma variedade de diferentes bibliotecas e frameworks específicos da linguagem de programação. A gem Ruby se integra com Ruby puro, Rails, Sinatra e outros frameworks disponíveis. O pacote Elixir se integra com Elixir puro e Phoenix. Essas integrações automáticas tornam mais fácil obter mais insights sobre as aplicações sem ter que adicionar [instrumentação](#instrumentation) do AppSignal manualmente. Leia mais sobre quais [integrações Ruby oferecemos](/ruby/integrations). ## Markers Markers são pequenos ícones usados em gráficos no AppSignal.com para indicar uma mudança. Isso pode ser um deploy de código usando um "Deploy marker" ou um evento especial com um "Custom marker". Esses custom markers podem ser qualquer coisa, desde operações de escalonamento, picos repentinos de tráfego ou quando um banco de dados está enfrentando problemas. Leia mais sobre [markers](/application/markers). ## Metadata Metadata é dado que fornece informações sobre outros dados. Metadata são informações sobre um erro ou problema de desempenho que fornece mais contexto aos dados coletados. Ao enviar metadata extra em uma [amostra](#samples), é mais fácil rastrear quais foram as circunstâncias em torno do problema específico. Por padrão, o metadata de uma requisição inclui o hostname no qual a issue ocorreu, a revisão SCM em que a aplicação está sendo executada e o ID da requisição da requisição da qual a amostra foi derivada. Também inclui dados como o caminho da requisição e o método da requisição para requisições web. ## Métricas O AppSignal fornece dois tipos de métricas. * [Métricas personalizadas](/metrics/custom) * [Métricas de host](/metrics/host-metrics) Métricas personalizadas permitem a coleta de dados de praticamente qualquer coisa. Com algumas linhas de código, é possível rastrear e gerar gráficos de dados como o número de usuários registrados, visitas a uma página, tamanhos de banco de dados, etc. Métricas de host são sobre dados do servidor em que uma aplicação está sendo executada. Dados como [uso de CPU](#cpu-usage), load averages, uso de memória, etc. dão mais insights sobre problemas de desempenho do que apenas o código em si. Talvez o espaço em disco esteja acabando, fazendo com que a aplicação rode muito mais lenta. Leia mais sobre [métricas](https://www.appsignal.com/tour/metrics) em nossa página de tour. ## Namespace Namespaces são mecanismos de agrupamento usados pelo AppSignal para diferenciar entre diferentes partes da mesma aplicação. Por padrão, o AppSignal divide uma aplicação em dois namespaces: "Web" e "Background". Requisições HTTP que estão sendo monitoradas pelo AppSignal serão adicionadas ao namespace "Web", e jobs realizados por bibliotecas de jobs em background são adicionados ao namespace "Background". Também é possível configurar seus namespaces para diferenciar entre requisições em uma aplicação e um painel de administração privado. Para mais informações sobre namespaces, consulte nossa documentação de [namespaces](/application/namespaces). ## Notificações O AppSignal envia notificações sempre que um problema é detectado em uma [aplicação](#applications). Essas notificações podem ser mensagens de e-mail, mensagens no Slack, uma notificação do PagerDuty e mais, dependendo de quais [integrações de terceiros](#third-party-integrations) estão configuradas. Enviamos notificações sobre [erros](#errors), [requisições lentas](#performance-issues) e alertas de [Detecção de anomalias](/anomaly-detection/) que ocorrem em uma aplicação usando uma [biblioteca](#libraries) do AppSignal. Uma vez que um evento problemático é detectado, uma notificação é enviada para alertar os usuários sobre um problema. ## Organizações Organizações são usadas para agrupar [aplicações](#applications) e [usuários](#user-account) para um negócio. Um negócio pode ter muitos usuários e clientes que podem ser notificados sempre que houver um problema com suas aplicações. O [Faturamento](/support/billing) para aplicações é feito no nível da organização, em vez de por aplicação. A [gestão de equipe](/organization/team/members) é facilitada usando organizações. Equipes inteiras podem ser convidadas para uma organização, então não há necessidade de compartilhar detalhes de login. Leia mais sobre organizações em nossa [documentação de Organizações](/organization). ## Owners [Organizações](#organizations) têm pessoas que gerenciam a organização. Esses owners decidem quem é membro de uma organização, em qual [time](#teams) eles pertencem ou não, e decidem como o faturamento é feito. Os owners da organização podem gerenciar tudo sobre uma organização e as [aplicações](#applications) que pertencem a ela. Se você não tem permissão para visualizar ou alterar algo, peça ao owner da sua organização para alterar para você ou dar a você mais permissão. ## Problemas de desempenho Usando o monitoramento de desempenho, é possível mergulhar em requisições individuais e ver quais partes de uma aplicação são lentas. Com essas informações, é possível encontrar e melhorar áreas problemáticas. Quando o AppSignal detecta uma requisição web ou operação lenta, ele enviará notificações, porque código lento pode ser tão prejudicial quanto um [erro](#errors) aparecendo. Problemas de desempenho são agrupados por [action](#actions) e [namespace](#namespace). Nas páginas de detalhes de problemas de desempenho, mais informações estão disponíveis sobre cada action. Nem todas as issues são uma "issue". Cabe a você determinar se uma requisição HTTP de 200ms é muito lenta. Potenciais requisições lentas e jobs em background são reportados como problemas de desempenho. Saiba mais sobre o que são [issues](#issues). Leia mais sobre o [recurso de desempenho](https://www.appsignal.com/tour/performance) em nossa página de tour. ## Push API A "Push API" do AppSignal é o endpoint da API usado pelo [agente](#agent) do AppSignal para enviar os dados coletados. Isso é diferente da [API](#api) normal do AppSignal, que é usada principalmente para ler dados e adicionar mais contexto aos dados enviados ao AppSignal. Essa Push API é a API onde a instrumentação da aplicação é enviada das aplicações usando a [Push API key](#push-api-key). ## Push API key A "Push API key" é uma chave de API somente de escrita usada por aplicações para se autenticar ao enviar dados aos servidores do AppSignal. Apps reportam dados à [Push API](#push-api) e se autenticam usando essa chave. Existem vários tipos de Push API keys que os apps podem usar para diferentes casos de uso. Todas as Push API keys podem ser encontradas na [página de configurações de Push & deploy](https://appsignal.com/redirect-to/app?to=info). * **Push API key no nível da organização:** A Push API key recomendada para integrações de back-end, como Ruby, Elixir, Node.js, Python e Go. Reconhecemos apps por uma [combinação de Push API key, nome do app e ambiente do app](/application/configuration), e criamos apps usando essas informações se ainda não existirem. * **Push API key no nível do app:** Após a criação, um app também recebe sua Push API key no nível do app. Essa chave pode ser usada para enviar dados a um app específico, mesmo que o app esteja configurado para usar um nome de app ou ambiente de app diferente. Isso é usado ao mover apps entre organizações sem perda de dados, ou quando nenhum nome de app ou ambiente de app pode ser definido, como para a integração [Vector](/vector). * **Front-end API key:** Essa chave é usada por apps que usam nossa [integração front-end](/front-end) para reportar dados e pode ser encontrada na seção "Front-end error monitoring". Observação: Essas chaves somente de escrita não devem ser confundidas com a [API key](#api-key) específica do usuário, que pode ser usada para autenticar na [API do AppSignal](#api) para recuperar dados sobre seus apps do nosso sistema. ## Tempo de resposta O tempo de resposta de uma action de uma aplicação é o tempo gasto processando a action. Quanto mais tempo uma action leva para ser executada, mais ela qualifica como um problema de desempenho. A duração dessa action é exibida no AppSignal.com para problemas de desempenho e em gráficos para controllers/jobs e no nível do host. ## Ruby Magic Você sabia que escrevemos artigos sobre a mágica que é Ruby? Sim! Chama-se Ruby Magic e você pode se inscrever em [appsignal.com/ruby-magic](https://blog.appsignal.com/ruby-magic). Uma lista de todos os artigos do Ruby Magic que escrevemos até agora pode ser encontrada em [nosso blog](https://blog.appsignal.com/). ## Amostras Quando uma requisição de página é lenta cem vezes seguidas, não é tão relevante ver todas as requisições lentas; uma amostra menor dessas requisições conta a mesma história. Em vez disso, o [agente](#agent) do AppSignal envia apenas um pequeno conjunto de problemas de desempenho aos servidores do AppSignal. Isso economiza dados enviados aos servidores, os dados processados no host da aplicação e nos servidores do AppSignal, enquanto ainda conta a mesma história sobre os problemas. ## Stroopwafels Também escrito como "stroopwaffles". No AppSignal, amamos stroopwafels. Já enviamos mais de 25.000 deles para clientes, amigos e conferências. Se você trabalha em uma empresa de tecnologia e já comeu um stroopwafel no escritório, é provável que tenha vindo de nós. Escrevemos um artigo inteiro sobre o que são stroopwafels e como você deve comê-los. Continue lendo para [se tornar um especialista em stroopwafels](https://blog.appsignal.com/blog/2016/02/01/stroopwafels-and-how-to-eat-them.html). ## Tags [Amostras](#samples) de issues de erro e problemas de desempenho podem ser marcadas. Marcando essas amostras, fica mais fácil encontrar e identificar certas issues. Marcando, é possível adicionar mais [metadata](#metadata) a uma amostra que pode ser usado em [templates de link](/application/link-templates) para vincular facilmente aos dados relevantes em sua aplicação. Leia mais sobre [como marcar requisições](/guides/tagging). ## Times Para gerenciar membros de [organizações](#organizations), os owners da organização podem utilizar times para dar acesso a aplicações. [Usuários](#user-account) que fazem parte de um time só podem acessar as aplicações às quais o time a que pertencem tem acesso. Se um usuário faz parte de mais de um time, esse usuário pode acessar todas as aplicações de todos os times aos quais pertence. Times dão gerenciamento de permissão aos [owners](#owners) de uma organização para limitar o acesso de usuários a aplicações sem a necessidade de múltiplas organizações. Leia mais sobre o [gerenciamento de times](/organization/team/teams) da organização. ## Integrações de terceiros O AppSignal.com fornece conexões com outros serviços, como Slack e PagerDuty, para alertar os usuários sobre problemas detectados de forma mais eficaz. Essas integrações podem ser gerenciadas através da UI no AppSignal.com em uma base aplicação-por-aplicação. Leia mais sobre [quais integrações de terceiros oferecemos](/application/integrations/). ## Transações Transações são criadas pelas [bibliotecas](#libraries) do AppSignal para cada requisição web monitorada e job em background. Dentro dessa transação, os agentes monitoram erros e código lento. Uma transação é criada no início de uma requisição web ou quando um job em background é iniciado. Uma vez que a requisição ou job termina ou falha, a transação é fechada e enviada ao [agente](#agent) para processamento. [Tags](#tags) e [metadata](#metadata) são adicionados no nível da transação para identificar mais facilmente diferenças entre amostras de transações. ## Throughput O throughput de uma aplicação é o número total de requisições enviadas através de uma action/job em um determinado período de tempo. O throughput pode diferir por action e host. No AppSignal.com, o throughput é exibido por action e mostrado em gráficos para cada host. ## TLS TLS significa Transport Layer Security. TLS é um protocolo criptográfico que fornece conexões seguras para redes de computadores, por exemplo, entre um servidor e um navegador web. ## Queue time Quando um servidor ou aplicação está ocupado processando muitas requisições, certas requisições podem ser enfileiradas antes de serem processadas. O tempo aguardando para ser processado é referido como "queue time". Como o queue time pode afetar negativamente a experiência dos usuários usando uma aplicação, essa métrica é rastreada pelo AppSignal para requisições HTTP e jobs em background. Para jobs em background, isso representa o tempo entre a requisição ser enfileirada (por uma requisição web) e ser pega pelo worker em background (sidekiq). ## Conta de usuário Cada usuário usando o AppSignal tem uma conta de usuário. Com essa conta de usuário, você pode configurar preferências de notificação. Muitos usuários podem pertencer a uma ou mais organizações. Não há necessidade de contas de usuário separadas para cada organização. [Organizações](#organizations) gerenciam quais usuários podem acessar quais aplicações e quem pode gerenciar o faturamento como um [owner](#owners).