wor-prof 0.1.0

Sign up to get free protection for your applications and to get access to all the features.
@@ -0,0 +1,308 @@
1
+ # Wor-Prof
2
+
3
+ Wor-prof (Wprof) is a gem for Ruby On Rails which its only purpose is to measure a RoR app's performance through a profile with different times of response. In order to accomplish that, Wprof uses ActiveSupport::Notifications (available in Rails since v4.0.2) to capture every action from his controllers. However, there's more. when using httparty in your project, you can capture every done request to external services. Do you have one or two methods that would like to know how long they take to execute? With Wprof you can find out.
4
+
5
+ Then, every data obtained can be reported in several ways, choose one from the Rails logger: database file, CSV text or go ahead and do a Post request wherever you want... Do it both synchronously or asynchronously.
6
+
7
+ ---
8
+
9
+ ## Let's begin.
10
+
11
+ The first step is the gem install (of course) and the way to do it is well known. However, just in case, you'll find the steps to follow next.
12
+
13
+ ### Installation
14
+
15
+ Add the next line to the gemfile from your Rails application:
16
+
17
+ ```ruby
18
+ gem 'wor-prof'
19
+ ```
20
+
21
+ And then, execute:
22
+ ```bash
23
+ $ bundle install
24
+ ```
25
+ **That's it!!** At server execution, WProf immediately begins to work with default settings, so you won't need to configure anything if it matches with your needs, otherwise you can check **Available Settings**.
26
+
27
+ ---
28
+
29
+ ## Register Types and how they works.
30
+
31
+ As register types, Wprof counts with the following.
32
+
33
+ * Controllers: every request realized to Rails' App that is handled by a Controller. (this is a default setting and cannot be disabled)
34
+ * HTTParty: every time an HTTParty method is involved.
35
+ * Own methods: an array of methods can be defined to be captured.
36
+ ``Only "controllers" are automatically profiled by just adding the gem, every other one will need an extra configuration or operation.``
37
+
38
+ ### HTTparty
39
+
40
+ HTTParty is a popular tool for Ruby that allows to easily make HTTP's requests.
41
+ If you're not used to the gem I recommend you to read more information in its repository, right [here!](https://github.com/jnunemaker/httparty)
42
+
43
+ In order to profile the requests made by HTTParty, you must include Wprof right after Httparty. This is:
44
+
45
+ ```ruby
46
+ class FooClass
47
+ include HTTParty
48
+ include Wprof
49
+ ```
50
+ What that does mean? Wprof make a wrapper over every called method as class methods, waits for the response and captures some of the needed data to generate the profile. This is why you **must include the module right after HTTParty**... Otherwise, it would simply not work.
51
+
52
+ By default, WProf defines the methods that are commonly used to generate a request (Get, Put, Delete, Post), however you can define or exclude some of that list. It's **strongly recommended not to add** HTTParty's methods without being completely certain that the result is what WProf will try to capture (See 'captured Data' to know which are they)
53
+
54
+ ### Own methods
55
+
56
+ Sometimes it may result useful to know how much an specific method is taking to execute, to this end Wor-prof can help you out.
57
+
58
+ There are two steps to accomplish that.
59
+
60
+ 1. Prepare an array of methods which you want to trace (check configuration section: "custom_methods")
61
+ 2. Include WProf to that method's class
62
+
63
+ Done, with this WProf will be registering the execution time of said method every time is being called and then it will report it.
64
+
65
+ ---
66
+
67
+ ## Available Configurations.
68
+
69
+ WProf contains a list of default settings which can all be altered by others availables as user's preferences demands. In order to do that, create a file in 'config/initializers' (RailsApp.Root >> config >> initializers >> wprof.rb). Inside, you must define the following configuration:
70
+
71
+ ```ruby
72
+ Rails.application.configure do
73
+ config.x.wprof.db_runtime = true
74
+ config.x.wprof.reporter_type = 'FILE'
75
+ end
76
+ ```
77
+ > In case of not correctly configuring an option or just skip it, the value would be default.
78
+
79
+ To avoid this configuration manually using the **configuration generator** with the command "rails generate wprof" (see generator section).
80
+
81
+ Following the complete list of available settings and their meaning.
82
+
83
+ ### config.x.wprof.db_runtime
84
+ Sets whether it shows or not the data "db_runtime" inside the report.
85
+
86
+ > Possible values: true o false
87
+
88
+ > Default: true
89
+
90
+ ### config.x.wprof.reporter_type
91
+ Sets report type, meaning, how to show the obtained data. There are currently 4 available types, see "Reports" section for more information.
92
+
93
+ > Possible values: LOGGER, FILE, DATABASE, EXTERNAL
94
+
95
+ > Default: LOGGER
96
+
97
+ ### config.x.wprof.csv_type
98
+ When the report is defined as a CSV file there are two ways of generate it.
99
+ * **MIX:** generates one CSV file where every data captured by WProf is saved. This file only contains 2 columns: in the first one is the field and in the second one the data.
100
+ * **SPLIT:** Divides storage in three different files, one for each record type. This significantly improves reading since every field is held as the file's header and the data in rows is split by comma... As it should be, of course... Why mix then?, I don't know, it could be useful for someone!
101
+ > Possible values: MIX, SPLIT.
102
+ > Default: SPLIT
103
+
104
+ ### config.x.wprof.async
105
+ Sets whether the report is being generated sinchronously or not. **Take note: asynchronous mode requires extra steps, see "asynchronism" section for more information.**
106
+ > Possible values: false, true
107
+ > Default: false
108
+
109
+ ### config.x.wprof.httparty_methods_to_trace
110
+ HTTParty's method captured by WProf. By default, more common ones are set and it's recommended not to modify.
111
+ This being said, there's no problem in taking out some of the array, however take special care in adding HTTParty's methods which doesn't return an http request.
112
+ > Possible values: what you want and need, must be an **array of strings**.
113
+ > Default: ['get', 'put', 'delete', 'post']
114
+
115
+ ### config.x.wprof.external_url
116
+ In case you configure reporter_type as External, you must indicate the URL which will receive the HTTP petition.
117
+ > Possible values: any string that corresponds to an URL. Example: 'http://example-url/reporter'
118
+ > Default: nil
119
+
120
+ ### config.x.wprof.external_headers
121
+ To add a header to the http request ("external" report type), you must define it in this setting. This must be a **HASH of RUBY**, exactly as HTTParty expects (internally Wprof uses HTTParty to send a request). An example would be:
122
+
123
+ ``` ruby
124
+ config.x.wprof.external_headers = { headers: {'User-Agent' => 'Httparty'}}
125
+ ```
126
+ > Possible : Any valid hash, must respect primary key as "headers" (check example below)
127
+ > Default: nil
128
+
129
+ ### config.x.wprof.custom_methods
130
+ If you want to capture response times of an specific method inside a class, it's not enough including the module, you'll need to indicate WProf exactly which is the one it has to capture.
131
+ This list of methods must be contained in this option in a **array of Ruby** and it has to be strings.
132
+ Example:
133
+ ``` ruby
134
+ config.x.wprof.custom_methods = [ 'my_great_method' ]
135
+ ```
136
+ > Possible values: any method's name in string format, within an array. Default: nil
137
+
138
+ ### config.x.wprof.file_path
139
+
140
+ When "FILE" is used as an output, this option allows you to choose the files destination. This must be a valid route, as string, with reading permission for Rails and also be a folder.
141
+ Example:
142
+ ``` ruby
143
+ config.x.wprof.file_path = '/home/mcolombo/examplefolder'
144
+ ```
145
+ > Possible values: any string that correctly represents a PATH to a directory.
146
+ > Default: Rails.root is used, so, root is Rails application.
147
+
148
+ ---
149
+
150
+ ## Generators.
151
+
152
+ WProf has two Rails generators availables.
153
+
154
+ ---
155
+
156
+ ### Configuration file Generator.
157
+
158
+ To begin to modify options from available settings, you must create a config file inside the 'config/initializers' (as mentioned in "available configurations" section). To avoid unnecessary steps and possible mistakes in the well known dangerous 'copy/paste', you can generate this file as a template with the following Rails command:
159
+
160
+ ```
161
+ rails generate wprof
162
+ ```
163
+ This generates a model of the configuration's file with all the available options seen in "available configurations" section.
164
+
165
+ ### Data Model Generator
166
+
167
+ An available option to report captured information is the same database Rails uses, the problem is, this requires defining the model. This generator will create all of the migration files and the models for using this option without having to worry for anything else.
168
+ ```
169
+ rails generate wprof_model
170
+ ```
171
+ This will generate the migration files and the models (even controllers in case you want to handle them!)
172
+ **Remember: in order to models be available in the case you still must run the migration.**
173
+ ```
174
+ rails db:migrate
175
+ ```
176
+
177
+ ---
178
+
179
+ ## Captured Data.
180
+
181
+ Data captured and reported by WProf vary depending on which record they come, although, all of them share some base data.
182
+
183
+ ### Base data (common to all)
184
+
185
+ * **transaction_id:** unique identifier for each transaction. This field is vital due to HTTParty's records and methods share this same identifier with the request that triggered this execution, allowing a complete execution trace of each one of them.
186
+ * **total_time:** Total execution time registered (in milliseconds).
187
+ * **start_dt:** Date and time field when register began.
188
+ * **end_dt:** Date and time field when register ended.
189
+
190
+ ### Unique for the controller.
191
+
192
+ * **code:** Response code sensed by the controller (Status), eg. 200, 404, etc.
193
+ * **controller:** Controller that handled the request.
194
+ * **url:** Endpoint that received the petition.
195
+ * **db_runtime:** total time when it was absorbed by the database (included in total_time).
196
+
197
+ ### Únicos para los Servicios (Httparty).
198
+
199
+ * **code:** Código de respuesta recibido (Status), ej. 200, 404, etc.
200
+ * **service_hostname:** Hostname del servicio consumido.
201
+ * **request_uri:** Uri del endpoint consumido.
202
+
203
+ ### Unique for services (Httparty).
204
+
205
+ * **method:** measured method's name.
206
+
207
+ ---
208
+
209
+ ## Reports.
210
+
211
+ Destination of the data, once is captured and processed, varies in order of user’s preferences Wor-Prof offers the following destinations for the information:
212
+ * **LOGGER:** Uses Rails.logger to show the information.
213
+ * **FILE:** Saves the info in one or several text files, split by comma (csv)
214
+ * **DATABASE:** Saves obtained data in the same database used by Rails (requires model preparation, see generator/s of data model)
215
+ * **EXTERNAL:** Does a POST petition with the data sended in the body in a JSON format (requires additional configuration)
216
+
217
+ > "Logger" as well as "File" don’t need additional configuration to work, however “Database” and “External” require some previous step.
218
+
219
+ ### Database Reporter
220
+
221
+ For **DATABASE** is necessary to generate a schema that allows information storage. To accomplish this, we provide a generator, however, if you want to manually generate WProf you need the following models (Migration files are exposed).
222
+
223
+ > Modelo: WprofController
224
+ ``` ruby
225
+ class CreateWprofControllers < ActiveRecord::Migration[5.0]
226
+ def change
227
+ create_table :wprof_controllers do |t|
228
+ t.string :transaction_id
229
+ t.float :total_time
230
+ t.datetime :start_dt
231
+ t.datetime :end_dt
232
+ t.integer :code
233
+ t.string :controller
234
+ t.string :url
235
+ t.float :db_runtime
236
+
237
+ t.timestamps
238
+ end
239
+ add_index :wprof_controllers, :transaction_id
240
+ add_index :wprof_controllers, :code
241
+ add_index :wprof_controllers, :url
242
+ end
243
+ end
244
+ ```
245
+ > Modelo: WprofService
246
+ ``` ruby
247
+ class CreateWprofServices < ActiveRecord::Migration[5.0]
248
+ def change
249
+ create_table :wprof_services do |t|
250
+ t.string :transaction_id
251
+ t.float :total_time
252
+ t.datetime :start_dt
253
+ t.datetime :end_dt
254
+ t.integer :code
255
+ t.string :service_hostname
256
+ t.string :request_uri
257
+
258
+ t.timestamps
259
+ end
260
+ add_index :wprof_services, :transaction_id
261
+ add_index :wprof_services, :code
262
+ add_index :wprof_services, :service_hostname
263
+ add_index :wprof_services, :request_uri
264
+ end
265
+ end
266
+ ```
267
+ > Modelo: WprofMethod
268
+ ``` ruby
269
+ class CreateWprofMethods < ActiveRecord::Migration[5.0]
270
+ def change
271
+ create_table :wprof_methods do |t|
272
+ t.string :transaction_id
273
+ t.float :total_time
274
+ t.datetime :start_dt
275
+ t.datetime :end_dt
276
+ t.string :method
277
+
278
+ t.timestamps
279
+ end
280
+ add_index :wprof_methods, :transaction_id
281
+ add_index :wprof_methods, :method
282
+ end
283
+ end
284
+ ```
285
+
286
+ ### External Request Reporter.
287
+ An option is sending data by HTTP wherever you want. Data obtained by Wprof will be sended in the body as JSON format. In order for this to work well it’s **necessary to configure destination’s URL**. Petition generated is POST and, when needed, you can configure the necessary HEADERS. If the URL is not configured, petition won’t be sended.
288
+ The options to be set are: external_url and external_headers. See Configurations section for more information.
289
+
290
+ ---
291
+
292
+ ## Asynchronism.
293
+
294
+ WProf by default reports all the information **synchronous**, although it’s possible to configure the tool in order to do this process **asynchronous**. To achieve this, you must first activate the option through config field "config.x.wprof.async = true", however this is not enough. For all of the report be made asynchronous, you must have functional and operational **Sidekiq**, since WProf uses it to that purpose. If you’re not familiar with the tool, you could give it a look to its [repository by clicking here!.](https://github.com/mperham/sidekiq).
295
+
296
+ ---
297
+
298
+ ## Handled errors.
299
+
300
+ Any error among the capture and report of the information **MUSTN’T** interrupt the normal functioning of your Rails application. If this is the case, please report it. During the execution, could show up two errors in application’s logger.
301
+ WProf ERROR when try parsing service response:
302
+ An error was raised when WProf tried to send data to reporter: This is the most common error and it will appear if the data sending to the selected destination (meaning Logger, Database, File o External) has failed.
303
+
304
+ ```WProf ERROR when try parsing service response:``` This error may appear if HTTParty wouldn’t be able to capture some data.
305
+
306
+ ```An error was raised when WProf tried to send data to reporter:``` This is the most common error and it will appear if the data sending to the selected destination (meaning Logger, Database, File o External) has failed.
307
+
308
+ ---
@@ -0,0 +1,297 @@
1
+ # Wor-Prof
2
+
3
+ Wor-prof (Wprof) es una gema para Ruby On Rails cuyo único objetivo es el medir el rendimiento de una aplicación RoR mediante un perfil de distintos tiempos de respuesta. Para lograrlo, Wprof utiliza ActiveSupport::Notifications (disponible en Rails desde la versión 4.0.2) para capturar toda acción de sus controladores. Pero no sólo eso, si usas httparty en tu proyecto también puedes capturar cada request realizada a servicios externos. Tienes uno o más métodos que también quisieras conocer cuánto se demoran en ejecutarse? Con Wprof puedes saberlo. Luego, cada dato obtenido puede reportarse de distintas formas, elige una entre el logger de Rails, base de datos, archivo de texto en formato CSV o bien realiza un request Post a donde quieras… hazlo de forma sincrónica o asíncrona.
4
+
5
+ ---
6
+
7
+ ## Comenzar.
8
+
9
+ El primer paso es instalar la gema (por supuesto) y la forma es bien conocida, pero por si acaso acá están los pasos a seguir.
10
+
11
+ ### Installation
12
+ Agregar la siguiente línea en el gemfile de tu aplicación Rails:
13
+
14
+ ```ruby
15
+ gem 'wor-prof'
16
+ ```
17
+
18
+ Y luego ejecute:
19
+ ```bash
20
+ $ bundle install
21
+ ```
22
+ **Eso es todo!!** Al correr el servidor Wprof comienza inmediatamente a trabajar con la configuración por defecto por lo que no hay que configurar nada si coincide con sus necesidades, pero si no es así puede consultar la sección de **Configuraciones Disponibles**.
23
+
24
+ ---
25
+
26
+ ## Tipos de registros y cómo funciona.
27
+
28
+ Como tipo de registros WProf cuenta con los siguientes.
29
+
30
+ * Controladores: Cada request realizada a Rails que es manejada por un *Controller*. (Esto viene por defecto y no puede desactivarse)
31
+ * HTTParty: Cada vez que se invoca un método de HTTParty.
32
+ * Métodos propios: Se puede definir un Array de Métodos a capturar.
33
+
34
+ ``Solamente "Controladores" son automáticamente perfilados con sólo agregar la gema, el resto necesita alguna configuración u operación extra.``
35
+
36
+ ### HTTparty
37
+ HTTParty es una popular herramienta para Ruby que permite realizar fácilmente peticiones HTTP. Si no está familiarizado con la gema le recomiendo leer más sobre está en el repositorio de la misma, [aquí!](https://github.com/jnunemaker/httparty)
38
+
39
+ Para poder perfilar las request que se hacen mediante HTTParty debe incluir Wprof justo después de Httparty. Es decir:
40
+ ```ruby
41
+ class FooClass
42
+ include HTTParty
43
+ include Wprof
44
+ ```
45
+ Qué significa esto? Wprof envuelve los métodos invocados como métodos de clase, espera la respuesta y captura algunos datos necesarios para generar el perfil. Es por esto que la inclusión del módulo debe ser **obligatoriamente** después de HTTParty... si esto no es así, sencillamente no funcionará.
46
+
47
+ Por defecto, WProf define los métodos que comúnmente se utilizan para generar una petición (Get, Put, Delete, Post), sin embargo puede definir otros o bien quitar alguno de esos de la lista. Es **fuertemente recomendado** no **agregar** métodos de HTTParty sin estar completamente seguro que el retorno de estos coincide con lo que WProf buscará capturar (puede consultar la sección "Datos Capturados" para conocer cuales son).
48
+
49
+ ### Métodos propios
50
+
51
+ Algunas veces puede resultar de utilidad conocer cuánto se demora un método específico en ejecutarse, para este fin Wor-prof puede extender una mano.
52
+
53
+ Para lograrlo se necesitan seguir 2 pasos.
54
+
55
+ 1. Preparar un array de métodos que se desean trazar (consulte la sección de configuración: "custom_methods")
56
+ 2. Incluir Wprof a la clase que tiene dicho método.
57
+
58
+ Listo, con esto Wprof estará registrando el tiempo de ejecución de dicho método cada vez que sea invocado y lo reportará.
59
+
60
+ ---
61
+
62
+ ## Configuraciones disponibles.
63
+
64
+ Por defecto Wprof continúe una lista de configuraciones por defecto, pero todas estas pueden ser modificadas por otras disponibles de acuerdo a las preferencias del usuario. Para lograr esto se debe crear un archivo en 'config/initializers' (RailsApp.Root >> config >> initializers >> wprof.rb).
65
+ Dentro del mismo se debe definir la configuración de esta manera:
66
+
67
+ ```ruby
68
+ Rails.application.configure do
69
+ config.x.wprof.db_runtime = true
70
+ config.x.wprof.reporter_type = 'FILE'
71
+ end
72
+ ```
73
+ > En caso de no configurar correctamente una opción u omitirla, se tomarán los valores por defecto.
74
+
75
+ Para evitar esta configuración manualmente utilizando el **Generador de Configuración** con el comando "rails generate wprof" (consulte la sección de generadores).
76
+
77
+ A continuación se ofrece la lista completa de configuraciones disponibles y sus significados.
78
+
79
+ ### config.x.wprof.db_runtime
80
+ Define si se debe mostrar o no el dato "db_runtime" dentro del reporte.
81
+ > Valores Posibles: true o false
82
+ > Por defecto: true
83
+
84
+ ### config.x.wprof.reporter_type
85
+ Establece el tipo de reporte, es decir, como exponen los datos obtenidos, existen cuatro tipo disponible actualmente, Ver sección "Reportes" para más información.
86
+ > Valores Posibles: LOGGER, FILE, DATABASE, EXTERNAL
87
+ > Por defecto: LOGGER
88
+
89
+ ### config.x.wprof.csv_type
90
+ Cuando se define el reporte como un archivo CSV existen dos formas de generarlos.
91
+ * **MIX:** Genera un único archivo CSV donde se guardan los datos de **todo** lo que captura WProf. Este archivo solo tiene 2 columnas: En la primera se guarda el campo y en la segunda el dato.
92
+ * **SPLIT:** Divide el almacenamiento en tres archivos distintos, uno por cada tipo de registro. Esto mejora significamente la lectura ya que cada campo está como encabezado del archivo y los datos en la filas separados por coma... como debe ser claro... ¿Por que mix entonces?, no sé, a alguno le puede servir!
93
+ > Valores Posibles: MIX, SPLIT
94
+ > Por defecto: SPLIT
95
+
96
+ ### config.x.wprof.async
97
+ Define si el reporte se gestará de forma Sincrónica o Asincronica. **Tome nota: la forma asincrónica requiere pasos adicionales, consulte la sección de "Asincronismo" para más información**
98
+ > Valores Posibles: false, true
99
+ > Por defecto: false
100
+
101
+ ### config.x.wprof.httparty_methods_to_trace
102
+ Métodos de HTTParty que WProf va a capturar. Por defecto se colocan los más comunes y se recomienda no modificar. Dicho esto, no hay problema en quitar algunos del array, pero tenga especial cuidado en agregar métodos de HTTParty que no devuelvan un request HTTP).
103
+ > Valores Posibles: Los que quiera, debe si o si ser un **Array** de strings.
104
+ > Por defecto: ['get', 'put', 'delete', 'post']
105
+
106
+ ### config.x.wprof.external_url
107
+ En caso de que se configure el reporter_type como External, se debe indicar la URL a la que se enviará la petición HTTP.
108
+ > Valores posibles: Cualquier cadena de texto que corresponda a una URL. Ejemplo: 'http://example-url/reporter'
109
+ > Por defecto: nil
110
+
111
+ ### config.x.wprof.external_headers
112
+ Para agregar una cabecera al request HTTP (para el tipo de reporte "External"), debe definirlo en esta configuración. La misma debe ser un **HASH de RUBY** tal cual como espera HTTParty recibir (internamente Wprof utiliza HTTParty para enviar el request). Un ejemplo de esto sería:
113
+ ``` ruby
114
+ config.x.wprof.external_headers = { headers: {'User-Agent' => 'Httparty'}}
115
+ ```
116
+ > Valores posibles: Cualquier hash válido, debe respetarse la primera clave como "headers" (ver ejemplo arriba)
117
+ > Por defecto: nil
118
+
119
+ ### config.x.wprof.custom_methods
120
+ Si desea capturar los tiempos de respuesta de un método específico dentro de una clase, no basta con incluir el módulo, debe indicarle a Wprof cual es exactamente aquel que desea capturar. Esta lista de métodos debe estar contenida en está opción dentro de un **Array de Ruby** y deben ser strings. Ejemplo:
121
+ ``` ruby
122
+ config.x.wprof.custom_methods = [ 'my_great_method' ]
123
+ ```
124
+ > Valores posibles: Cualquier nombre de método en formato string, contenido en un array.
125
+ > Por defecto: nil
126
+
127
+ ### config.x.wprof.file_path
128
+
129
+ Cuando se utiliza "FILE" como salida de datos, esta opción permite elegir la ruta de destino de los archivos. Esta debe ser una ruta válida, en formato string, con permisos de escritura para la aplicación Rails y cuyo último valor debe ser una carpeta. Ejemplo:
130
+ ``` ruby
131
+ config.x.wprof.file_path = '/home/mcolombo/examplefolder'
132
+ ```
133
+ > Valores posible: Cualquier string que represente correctamente un PATH hasta un directorio.
134
+ > Por defecto: Se utiliza 'Rails.root', es decir, la raíz de su aplicación Rails.
135
+
136
+ ---
137
+
138
+ ## Generadores.
139
+
140
+ WProf tiene disponible dos [generadores de Rails](https://guides.rubyonrails.org/command_line.html#rails-generate) disponibles.
141
+
142
+ ---
143
+
144
+ ### Generador del archivo de Configuración.
145
+
146
+ Para comenzar a modificar las opciones de configuración disponibles, debe crear un archivo de configuración dentro de los 'config/initializers' (como se mencionó en la sección "Configuraciones disponibles"). A favor de evitar pasos innecesarios y posibles equivocaciones en los peligrosos 'copy/paste', puede generar este archivo como un template con el siguiente comando Rails:
147
+
148
+ ```
149
+ rails generate wprof
150
+ ```
151
+ Esto generará un modelo del archivo de configuración, con todas las opciones disponibles vistas en la sección "Configuraciones disponibles".
152
+
153
+ ### Generador del modelo de datos
154
+
155
+ Una opción disponible para reportar la información capturada es la misma Base de Datos que utiliza Rails, pero el problema de esto es que se requiere justamente definir el modelo. Este generador creará todos los archivos de migración y los modelos para poder utilizar esta opción sin preocuparse por nada más.
156
+ ```
157
+ rails generate wprof_model
158
+ ```
159
+ Esto generará los archivos de migración y los modelos (incluso los controladores por si desea manejarlos!)
160
+ **Recuerde que para que los modelos se encuentren disponibles en la base aún debe correr la migración**
161
+ ```
162
+ rails db:migrate
163
+ ```
164
+
165
+ ---
166
+
167
+ ## Datos capturados.
168
+
169
+ Los datos que captura y reporta WProf varían de acuerdo a que tipo de registro proviene, sin embargo, todos comparten algunos datos base.
170
+
171
+ ### Datos base (comunes para todos)
172
+
173
+ * **transaction_id:** identificador único de cada transacción. Este campo es de vital importancia debido a que los registros de HTTParty y Métodos comparten este mismo identificador con el Request que disparó esta ejecución permitiendo una traza completa de la ejecución de cada uno.
174
+ * **total_time:** Tiempo total de ejecución registrado (en milisegundos).
175
+ * **start_dt:** Campo de Fecha y Hora en que comenzó a registrarse.
176
+ * **end_dt:** Campo de Fecha y Hora en que finalizó el registro.
177
+
178
+ ### Únicos para el Controlador.
179
+
180
+ * **code:** Código de respuesta enviado por el controlador (Status), ej. 200, 404, etc.
181
+ * **controller:** Controlador que manejó el request.
182
+ * **url:** endpoint que recibió la solicitud.
183
+ * **db_runtime:** Tiempo total que fue absorbido por la Base de Datos (incluido en el total_time).
184
+
185
+ ### Únicos para los Servicios (Httparty).
186
+
187
+ * **code:** Código de respuesta recibido (Status), ej. 200, 404, etc.
188
+ * **service_hostname:** Hostname del servicio consumido.
189
+ * **request_uri:** Uri del endpoint consumido.
190
+
191
+ ### Únicos para los métodos.
192
+
193
+ * **method:** Nombre del método que fue medido.
194
+
195
+ ---
196
+
197
+ ## Reportes.
198
+
199
+ El destino de los datos, una vez que son capturados y procesados, varía de acuerdo a las preferencias del usuario. Wor-Prof ofrece los siguientes destinos para la información:
200
+ * **LOGGER:** Utiliza Rails.logger para mostrar la información.
201
+ * **FILE:** Guarda la información en uno ó varios archivos de texto separados por coma (csv)
202
+ * **DATABASE:** Almacena los datos obtenidos en la misma base de datos que utiliza la aplicación Rails (requiere preparar el modelo, ver generadores/generador del modelo de datos)
203
+ * **EXTERNAL:** Realiza una petición POST con los datos enviados en el cuerpo en formato JSON. (requiere configuración adicional)
204
+
205
+ > Tanto "Logger" como "File" no necesitan configuración adicional para trabajar, sin embargo "Database" y "External" requieren pasos previos.
206
+
207
+ ### Database Reporter
208
+
209
+ Para **DATABASE** es necesario generar un esquema que permita almacenar la información. Para lograr esto ponemos a disposición un generador, sin embargo, si se desea generar manualmente WProf necesita los siguientes modelos (se exponen los archivos de Migración).
210
+
211
+ > Modelo: WprofController
212
+ ``` ruby
213
+ class CreateWprofControllers < ActiveRecord::Migration[5.0]
214
+ def change
215
+ create_table :wprof_controllers do |t|
216
+ t.string :transaction_id
217
+ t.float :total_time
218
+ t.datetime :start_dt
219
+ t.datetime :end_dt
220
+ t.integer :code
221
+ t.string :controller
222
+ t.string :url
223
+ t.float :db_runtime
224
+
225
+ t.timestamps
226
+ end
227
+ add_index :wprof_controllers, :transaction_id
228
+ add_index :wprof_controllers, :code
229
+ add_index :wprof_controllers, :url
230
+ end
231
+ end
232
+ ```
233
+ > Modelo: WprofService
234
+ ``` ruby
235
+ class CreateWprofServices < ActiveRecord::Migration[5.0]
236
+ def change
237
+ create_table :wprof_services do |t|
238
+ t.string :transaction_id
239
+ t.float :total_time
240
+ t.datetime :start_dt
241
+ t.datetime :end_dt
242
+ t.integer :code
243
+ t.string :service_hostname
244
+ t.string :request_uri
245
+
246
+ t.timestamps
247
+ end
248
+ add_index :wprof_services, :transaction_id
249
+ add_index :wprof_services, :code
250
+ add_index :wprof_services, :service_hostname
251
+ add_index :wprof_services, :request_uri
252
+ end
253
+ end
254
+ ```
255
+ > Modelo: WprofMethod
256
+ ``` ruby
257
+ class CreateWprofMethods < ActiveRecord::Migration[5.0]
258
+ def change
259
+ create_table :wprof_methods do |t|
260
+ t.string :transaction_id
261
+ t.float :total_time
262
+ t.datetime :start_dt
263
+ t.datetime :end_dt
264
+ t.string :method
265
+
266
+ t.timestamps
267
+ end
268
+ add_index :wprof_methods, :transaction_id
269
+ add_index :wprof_methods, :method
270
+ end
271
+ end
272
+ ```
273
+
274
+ ### External Request Reporter.
275
+ Una opción es enviar los datos por HTTP donde desee. Los datos obtenidos por Wprof serán enviados en el cuerpo como un JSON. Para que esto funcione bien es **necesario configurar la URL de destino**. La petición que se genera es POST y de ser necesario puede **configurar los HEADERS necesarios**. Si la URL no se configura, la petición no será enviada.
276
+
277
+ Las opciones a configurar son: external_url y external_headers. Consulte la sección de Configuraciones para más información.
278
+
279
+ ---
280
+
281
+ ## Asincronismo.
282
+
283
+ WProf por defecto reporta toda la información de manera ***sincronica**, sin embargo es posible configurar la herramienta para que este proceso lo haga de forma **asincronica**. Para lograr esto se debe en primer lugar activar la opción mediante la configuración del campo "config.x.wprof.async = true", sin embargo esto no es suficiente.
284
+ Para que todo el reporte se efectúe Asincrónicamente, es necesario tener funcional y operativo **Sidekiq**, ya que WProf lo utiliza para tal fin. Si no está familiarizado con la herramienta, puede buscar más información en el [repositorio de la misma haciendo click aquí!](https://github.com/mperham/sidekiq).
285
+
286
+ ---
287
+
288
+ ## Errores manejados.
289
+
290
+ Cualquier error dentro del proceso de captura y reporte de la información **NO DEBERIA** interrumpir el normal funcionamiento de su aplicación Rails. Si esto es así, por favor **reportelo**.
291
+ Durante la ejecución, podrían aparecer dos errores en el Logger de la aplicación.
292
+
293
+ ```WProf ERROR when try parsing service response:``` Este error puede mostrarse si no fue posible capturar algún dato por parte de HTTParty.
294
+
295
+ ```An error was raised when WProf tried to send data to reporter:``` Este es el error más típico y se mostrará en caso de que el envío de datos al destino seleccionado (es decir Logger, Database, File o External) haya fallado.
296
+
297
+ ---
@@ -0,0 +1,42 @@
1
+ class WprofGenerator < Rails::Generators::Base
2
+ desc 'This generator creates an initializer file for Wor-Prof!'
3
+ def wor_prof_init
4
+ create_file 'config/initializers/wprof.rb', init_wprof
5
+ end
6
+
7
+ private
8
+
9
+ def init_wprof
10
+ <<~CONTENT
11
+ # -----------------------------------------
12
+ # Uncomment and set for use custom options.
13
+ # -----------------------------------------
14
+ Rails.application.configure do
15
+ ## Save DB Runtime?: Default: true
16
+ # config.x.wprof.db_runtime = true
17
+ ## Reporter Type (¿When we will save our data?): 'LOGGER' by default.
18
+ ## Another options: 'FILE' (For CSV), 'DATABASE' (For Rails DB), 'EXTERNAL' (For external API).
19
+ # config.x.wprof.reporter_type = 'LOGGER'
20
+ ## CSV Type (One CSV file for each type of data or all together)
21
+ ## 'SPLIT' by default, Options: 'MIX'
22
+ # config.x.wprof.csv_type = 'SPLIT'
23
+ ## Reporter must be work async? Default: false
24
+ # config.x.wprof.async = false
25
+ ## Httparty Methods to wrapper.
26
+ # config.x.wprof.httparty_methods_to_trace = ['get', 'put', 'delete', 'post']
27
+ ## External URL for hit when Reporter Type is EXTERNAL
28
+ ## DEFAULT: nil
29
+ # config.x.wprof.external_url = 'http://example-url/reporter'
30
+ ## Define Headers for Reporter Type when is EXTERNAL.
31
+ ## Must be a Hash (see HTTPARTY doc for more info)
32
+ ## DEFAULT: nil
33
+ # config.x.wprof.external_headers = { headers: {'User-Agent' => 'Httparty'}}
34
+ ## Define your Custom Methods here! (Must be an Array)
35
+ # config.x.wprof.custom_methods = [ 'my_great_method' ]
36
+ ## Define your own path for save Files when Reporter Type is FILE
37
+ ## By default Wor-Prof use Rails.root
38
+ # config.x.wprof.file_path = '/home/mcolombo/examplefolder'
39
+ end
40
+ CONTENT
41
+ end
42
+ end
@@ -0,0 +1,14 @@
1
+ class WprofModelGenerator < Rails::Generators::Base
2
+ desc 'This generator creates all model for use Wor-prof witch reporter_type as Database'
3
+ def wprof_migrations
4
+ making_wprof_migrations
5
+ end
6
+
7
+ private
8
+
9
+ def making_wprof_migrations
10
+ generate 'model', 'WprofController transaction_id:string:index total_time:float start_dt:datetime end_dt:datetime code:integer:index controller:string url:string:index db_runtime:float'
11
+ generate 'model', 'WprofService transaction_id:string:index total_time:float start_dt:datetime end_dt:datetime code:integer:index service_hostname:string:index request_uri:string:index'
12
+ generate 'model', 'WprofMethod transaction_id:string:index total_time:float start_dt:datetime end_dt:datetime method:string:index'
13
+ end
14
+ end